Program to log off idle users

Dan Schlitt dan at sci.ccny.cuny.edu
Thu Oct 11 04:08:36 AEST 1990


In article <1990Oct4.135333.19139 at warwick.ac.uk> cudcv at warwick.ac.uk (Rob McMahon) writes:
>
>The trouble with all these idle timeout schemes is that they rely on the idle
>time on the particular /dev/tty device.  
>
>1) You don't really want to kill all such sessions, what about people who just
>have a window open from their workstation, or are running a dumb terminal pty
>handler like `screen', `pty', ...  Against that you probably do want to kill
>people who have come from a terminal server, so you have to do some horrible
>kludges along the lines of
>
>	if ( hard-wired-terminal ||
>	     pseudo-terminal-coming-from-terminal-server ) ...
>
>2) This just doesn't work.  If an application is talking to /dev/tty instead
>of the particular port, it's the times on /dev/tty, not /dev/tty?? that get
>updated.  Our most popular editor round here works like this.  Even the ones
>that try to be clever and go hunting down the process list looking for busy
>processes don't work, after 127 seconds you can't tell how long a process has
>been idle:

Kermit uses /dev/tty.  The scheme described in the original article
logs folk who are doing big kermit transfers off right in the middle
of the transfer.  Causes angry users.
>
>So how do you tell I hadn't really gone away for 27 minutes, but just stopped
>to follow up to this article ?  I seriously would like to know the answer,
>because we get dozens of naive users who do just walk away from the terminal,
>and yes, we do tell them the importance of logging out.  The lucky ones just
>get a nasty piece of mail from me.  The unlucky ones have all their files
>moved to a `...' directory and come crying to me for help.  The really unlucky
>ones have all their files removed (yes, I have seen this).
>
When I took over the system management here there was a idle terminal
killer of the sort described that was run every 20 minutes.  There
were cases like the kermit users where I needed to make exceptions.
The exceptions got so numerous that it was getting painful.  At about
that time there was a discussion of the topic in this news group or
one like it.  I believe it was Doug Gwyn who presented the arguments
that convinced me that the whole effort was misguided.  It just
wouldn't work with the coming window systems and other pty oriented
things.

What I do now that seems to work is to use a hacked version of csh
which has a timeout if it sits at the prompt too long.  The timeout is
set by a variable in the user's environment.  The above mentioned
discussion convinced me that allowing the users to control the timeout
was essential.  This doesn't catch the folk who sit in emacs all day
but it does take care of the careless.  In addition I run an
idlekiller of the sort described in the original article about 3 times
a day -- once after most people have gone home and once just before
they arrive for the day and once after midnight.  This catches the
forgetful emacs users.

I don't get complaints anymore.  And more astonishing -- very, very
few people get logged out by the idlekiller.

I don't know what to suggest to those of you who are sourceless except
to ask your vendor for this capability.
-- 
Dan Schlitt                        Manager, Science Division Computer Facility
dan at sci.ccny.cuny.edu              City College of New York
dan at ccnysci.uucp                   New York, NY 10031
dan at ccnysci.bitnet                 (212)650-7885



More information about the Comp.unix.admin mailing list