Think "idleout". Logmon, by Computronics is an inactivity
monitoring tool with a lot of power.
Installation is simple, though a registration step requires that
you contact Computronics (by email, fax or voice) to obtain a setup
code. Most companies that require this now also have a web page to
get the code. I opted for the email option, which caused me some
trouble- my first email went astray so naturally Computronics never
replied, and while the reply to the second was quick, the setup
code was wrong- the person sending it mistook a "I" for a "1". This
was corrected immediately when I reported that the code wouldn't
work, but I have to wonder why it happened at all- isn't cut and
paste available in Illinois?
Of course it is. But it turns out that one of the
employees who handles this function didn't know how. This review
prompted her boss to train her- I'm sure that makes her much
happier (it must have been annoying re-typing license codes) and it
will also stop anyone else from getting incorrect codes
After successfully installing the correct code, I was ready to
start the "sdc" daemon that does all the work. You control sdc
either by manually editing files, or using the "logmon" command.
That's where I immediately ran into trouble; the logmon command
just hung, and when I deleted out, it complained that it couldn't
connect to the sdc daemon. After a half second of reflection, I
realized that I block all network ports that I don't need (see
naturally "logmon" was being blocked. A "netstat -an" showed me
what it was trying to do: I was a little surprised to see that it
was using my "outside" (real) ip address rather than 127.0.0.1.
However, reading the manual showed me that "logmon" is designed to
be run from any node, not necessarily the node that "sdc" is
running on. I personally think it would be better to have a choice
in this; I'd rather lock this down to localhost. It's not a major
problem, though: I adjusted my firewall rules to allow sdc to
communicate on its port (5794) and all was fine. These issues
probably should be mentioned in the manual just for
I found Logmon initially quite confusing, and I couldn't seem to
get un-confused from the manual. Fortunately, Computronics gave me
immediate and detailed email answers to my questions, so I wasn't
stymied very long. I've suggested to them that a few step by step
examples in the manual would be useful; perhaps they will be able
to do that soon.
Out of the box, Logmon is configured to never log off "root",
and to send a warning to everyone else after 60 minutes of
inactivity. If you want to change that default action, you need to
first understand the flow of the profiles.
As you can see, the main menu of Logmon
presents you with several choices. Briefly, these are:
These are what will happen and when it will happen. For the
moment, don't worry about how a particular user gets selected so
that a particular action will apply to them; you'll see how that
works shortly. The two actions initially supplied are the "none"
action (which does nothing) and "action_a", which warns after 60
minutes and kills two minutes later as mentioned above. I'll get
into that in more depth below.
Code is not necessarily needed, and is going to confuse you if
you don't yet understand the full flow of what happens in Logmon.
However, you do need to understand that Code is what causes an
Action to happen. Normally, you would just map Code straight
through so it effectively does nothing but select the Action that
you want. In such a case, Code seems superfluous: it really does
nothing useful, and is simply an extra step you have to get through
to get what you want done. I'll cover the more advanced use of this
These let you map different Codes (which, remember, ultimately
cause the warn/kill actions to run) to different times of the day.
The default supplied entry has just one Time entry: 0000, which
means it applies all day long. Again, I'll get into more details on
A user can be an individual login (root), a group (sys,group,
etc) or a tty (tty1A). Wild cards are allowed (using Unix style
regex, which is a nice feature). For example, the TTY name "ttyp*"
would match all pseudo ttys, "tty[a-c]*" would match ttya, ttyb and
ttyc ports. The initial Logmon users are "root" (obviously the root
user) and "default", which is everyone else. A User entry points to
a Limit entry, which in turn selects a Code, which selects (or
normally justs maps directly to) an Action.
That's the flow: the sdc daemon is watching user processes. If it
finds a match in the User section, it selects the Limit that is
specified for the user. The Limit is broken down by time of day, so
sdc selects the appropriate Code entry for whatever time it is now.
In our simple case, the Code entry just maps directly through to an
Action, which then runs the appropriate script.
This flow means that you need to work bottom-up if you are going
to be defining new Actions, Codes, or Limits. For example, if you
want the accounting group to have a 2 hour grace period, you need
to start with an Action that allows that and work up. I found that
a little clumsy, and wished that I could just define new entries
from the pick list and work top-down, but then again this is not
something you'll be doing constantly, so a few inconveniences are
Actions in depth
Here's the default Action screen:
If you select "View" on "action_a", you get:
I've changed the default time (which was 60 minutes) to 10
minutes here. That does have immediate effect, but you'll need to
save the profiles (I'll get to that later) to make the change
Understand that you can have more actions than what Logmon
provides by default. The simplest way to create a new action is to
copy an existing one and modify it. So, for example, I might copy
the "default" action" to one I call "15min". I'd then modify that
to have a 15 minute time before it sends a warning. I'd leave
everything else alone. Note that Actions have levels, and that sdc
keeps track of what level has been reached, so it will know that it
has executed the "warn1" script and that "kill_coke" comes next..
but if the user has activity, it resets to start over at the
You could have an Action that looks like this:
That's going to warn the user three times at 15 minute
intervals, and then finally log them out. Note that the first
warning uses the "warn1" script, but the others use "warn2"- you
could define a "warn3" script and so on, but there's nothing wrong
with the stock scripts.
The supplied scripts are "warn1" and "warn2", "kill" and
"kill_coke". The "kill" only kills the idle process; "kill_coke"
kills all of it's descendants (in reverse order) also.
In all cases, when editing any of these profiles, you can hit
CTRL-E to get a pick-list of available choices. Here's the
pick-list for scripts while editing an Action:
Ordinarily, it shouldn't be necessary to write your own scripts.
If you do need to modify them, you'll find them in
/usr/logmon/scripts, and they are just shell scripts, easy to
understand and modify. However, the supplied scripts should be fine
for just about everyone. Just remember that the Inactivity is
cumulative while the user is idle; it's not total elapsed time when
you have more than one script line in an Action profile.
Code in depth
As explained above, normally the Code entry is really
superfluous: it does nothing, it just selects a specific Action and
thus seems to be useless. What it is, however, is a place where you
can divert the flow and cause different Actions to be taken based
on the return value of a script or program YOU write.
The name and location of the script is normally
/usr/logmon/code_check (that can be changed in "logmon.cnf"). You
probably were expecting (I was) that there would be a different
script for each defined Code, but that's not the way it works. The
default script just returns "default", which is why when you define
a Code you use "default" in the return value.
The script gets passed the user name, group, tty, and the
current idle time. If you wanted to select a different action, you
would modify the script (/usr/logmon/code_check) so that it
returned something different- for example it might return "ok" or
"rightnow" in addition to "default", dependent, of course, upon the
variables passed. Your Code profile would list each of these, with
a different Action for each. This shows such a profile:
While this is useful, I think it could have been implemented
better by having specific scripts for each Code profile. As it is,
if you define custom return codes because you need them for one
particular case, you'll need to arrange to handle those possible
return values in each other Code profile you have. Of course, you'd
probably just call the same Action for each return in the other
profiles, but it would be easier if the script were specific to the
Defining a Code entry like this is the only way to handle
differentiating between weekends, holidays, etc. I think I'd like
to see direct support for those conditions without external
programming like this, but that's just my opinion: it may very well
be that most sites wouldn't have different idle rules at such
Limits in depth
Limit profiles are simply time of day. The time you list in the
left hand column is the time the specified Code set will be called;
listing another time and Code set effectively ends that set, and
there is an implied 2359 entry that limits it to the day. So a
Limit like this:
covers the whole day, but if you added Line 1
with 1700 and the Code set "evening", then the "default" would only
be called from midnight to 5:00 PM, and then "evening" would take
I suspect that most folks wouldn't need more than the two
supplied Code sets (default and none) but perhaps I'm just not
being imaginative enough.
Users in depth
It's the darn users that this is all about, after all, and I've
already pointed out the flexibility of that. Again, a user can be
an individual login (root), a group (sys,group, etc), or a TTY and
regex style wild cards are allowed. The User Profile screen is
You can see I've added several users and a TTY entry. This, of
course, the place where politics come into play: you can't log off
the President, or maybe you can but it depends upon what he's doing
(that's a place where a Code script might help, but see below
also). Or maybe the "accounting" group needs special treatment.
Whatever it is, this is probably where most sites need to do the
Although theres a lot of flexibility with just what I've described
so far, it's not quite enough. For example, if I'm telneted out to
another site, I will look "idle" on this machine. Therefore, Logmon
provides a special Rules profile that can handle that situation:
That's all it takes to keep a telnet session from being kicked off,
but the Rules profile has other uses, too. Logmon works by
examining CPU usage, and some processes always generate some usage
even when they are idle. The rule file can list those commands,
specifying a non-zero CPU time. What this means is that Logmon will
consider the process to be idle if it only has "that much"
activity. How do you figure out what value to put there? Only by
trial and error. Note that any GUI login exhibits this behavior;
see Piddle for a more complete
discussion of this problem.
The Online Menu
This is poorly named; it should probably really be called
Administration. Unfortunately, one of its sub-menus already has
that name (I would have called that "Control"), but there's useful
stuff here. One of the nicest features is to be able to Suspend the
daemon- stop it from acting on rules. The Users choice shows the
status of the users- how long they have been idle, and when the
next Action will be taken. Very helpful is the inclusion of WHICH
action will be taken; if you have confused yourself with too many
conditions, this is a reality check.
Another unfortunately named menu is Persist (under Admin). This
is the Save profiles choice; it really shouldn't be buried in here,
it should be out front and called Save. However, you probably
aren't going to be diddling with this every day, so the
inconvenience certainly isn't a big problem.
All in all, Logmon is well done and has the flexibility most
sites will want. You can download a limited time demo from Computronics web site; they also
sell several other interesting tools.
Got something to add? Send me email.
Increase ad revenue 50-250% with Ezoic
More Articles by Tony Lawrence
Find me on Google+
© 2011-05-06 Tony Lawrence