I'm interested in logging out users that have not sent anything to stdin in [x] minutes. Can this be done in Linux?

Our users log in and are sent into a program rather than a typical shell prompt. What I'd like to do is monitor input in a non-polling fashion and log out a user who has not entered anything in [x] minutes.

For fun, I ran ltrace on the program in question, and monitored for "get" commands (getc, etc). I was able to detect the return of some getc( )s, however it seems as though some of the input is retrieved through a forked process. I tried running ltrace on this program with "fork trace" on, and the program dumped and I didn't proceed further.

I assume Linux is suitably equipped to handle this task. Thanks for any input!

Our users log in and are sent into a program rather than a typical shell prompt.
...then they'll use keepalives to thwart your timeout policy :-]
OTOH, if you add a (too short) fixed session timeout they'll stand a chance loosing data.
What application we're talking about (URI?)?
Does it keep per user session state?
Does it allow for interaction?
IOW, can you send users messages?

It's a third party application that is launched inside of a bash script. So perhaps my initial post was misleading!

Anyway, the application is used to look up account information, and should be receiving input from employees with intervals of inactivity of no longer than a few minutes, I imagine. I do have concerns about it, which you touch upon, but I was asked to look into this by my boss, so here I am.

I was looking around for ways to do this, and didn't really find anything outside the bash "auto-logout" variable, which doesn't take effect until users drop back into the shell. So, I played around with ptrace for a few days, and had a good time and learned some things, but I really don't want to use that solution since wrapping this application on a step-by-step machine instruction basis for 200+ users would put a heavy (and unjustifiable) burden on the system.

I'm thinking that since Linux represents everything as a file, I could somehow listen on /dev/stdin so I could grab any input before this application gets it. This app is "feisty" in that it forks to receive input sometimes. Perhaps, though, I could redirect the standard input to this application so that it gets it from a program I created? Can this be done dynamically like this? Or will the application wait until stdin receives EOF?

If you know the name of the app, or user, you could just use
ps -ef
and check the STIME column (start time) or TIME column (time used).
Or use 'last' cmd and get the start (login) time of each user.

This morning, I was playing with named pipes and I noticed that the timestamp on the file (or at least the timestamp printed by bash, whatever it may be bound to) was set to the last time the file was written to. I guess this makes sense since that's how it works for "other" files. I suppose I should have thought about this before!

Now to relate it to my predicament: Can I listen to changes being made to this file? I remember reading a while ago that Linux has a way of listening to file and directory changes in a non-polling manner. Is this true? Does anyone know the name of this capability/library?

It looks like epoll(2) is exactly what I'm looking for, however epoll is not fully functional (or even available, really) in the 2.4 kernel. I need to be able to do this in 2.4, so I guess epoll is out of the question.

How about a FAM based app?

FAM would be great, but I don't like the idea of installing a kernel module just to do this. Cool project, though!

And it does look like the later 2.4 builds come with epoll, but I don't really want to upgrade the kernel either, though I'd be more willing to do that. However, like I said, the timestamps are always the current time, so I don't know how reliable this method is.