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 Ipfilter) so 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 completeness.
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:
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 later.
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 this later.
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.
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 all right.
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 permanent.
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.
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 Code entry.
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
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 control.
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.
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 shown below:
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
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.
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.
More Articles by Tony Lawrence © 2011-05-06 Tony Lawrence