APLawrence.com -  Resources for Unix and Linux Systems, Bloggers and the self-employed


© September 2000 Tony Lawrence

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 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:

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 all right.

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 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 top.

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 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 times.

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 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.

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 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 most finagling.

Other Issues

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.

(OLDER)    <- More Stuff -> (NEWER)    (NEWEST)   

Printer Friendly Version

-> Logmon inactivity monitor


Inexpensive and informative Apple related e-books:

Take Control of Parallels Desktop 12

iOS 10: A Take Control Crash Course

iOS 8: A Take Control Crash Course

Digital Sharing Crash Course

Take Control of Apple Mail, Third Edition

More Articles by © Tony Lawrence

Fri Feb 5 15:59:45 2010: 8033   vicjalan


I find this very interesting, thanks. Just a note your link is pointing to www.computron.com. I believe you really want to link to www.computronics.com. It took me a while :)


Fri Feb 5 16:07:09 2010: 8034   TonyLawrence


The link was probably good when this was written, but things change .. I'll fix it and thanks!


Printer Friendly Version

Have you tried Searching this site?

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more.

Contact us

Printer Friendly Version

Any problem in computer science can be solved with another level of indirection. (David Wheeler)

Linux posts

Troubleshooting posts

This post tagged:


Unix/Linux Consultants

Skills Tests

Unix/Linux Book Reviews

My Unix/Linux Troubleshooting Book

This site runs on Linode