v11i020: Idle demon

[Kent Paul Dolan]

[Sorry if you see this twice; I messed up the attribution on the first
 one, and only caught it and sent a replacement and a cancel several
 hours later.]

tadguy at abcfd01.larc.nasa.gov (Tad Guy) writes:

>peltz at cerl.uiuc.edu (Steve Peltz) writes:

[xanthian (me!) wrote:]

>> >                     ...  I'd be a little huffy about having my kermit
>> >session killed in mid-download because I hadn't sent a keystroke in a
>> >while.
>> 
>> But, but, kermit (and all other error-correcting download protocols) send in
>> keystrokes all the time!
>
>Except that kermit uses /dev/tty, so on many UNIXes, the real tty line
>appears idle, even though characters are going by all the time...

[Thanks, Tad.]

More pertinent, kermit was just an example.  I've worked in
user support on timeshare systems where everyone edited huge
files online for 7.5 hours straight without a save (saves
took a _long_ time), then all hit "s"ave essentially at once
(to go home), the system got so loaded down that saves took
over 0.5 hour, the users got automatically logged off for
lack of keyboard input (the save locked the terminals
keyboards, so they couldn't even sit their bouncing the
backspace key to stay alive, or whatever), their files were
_truncated_ at the point where the save died, and their
entire day's work was lost (not to mention the nuisance of
trying to get several large files restored on a system with
crowded disks).  The timeshare site's sysops thought this
was perfectly acceptable behavior and wouldn't change it.

The moral of the story is that an idle terminal is not a
correct indication that the system is doing no useful work
for the user.  One must check for suspended or background
tasks, a foreground task other than the shell, and probably
several other precautions before deciding that a user is
really idle.

[Most safety checks that protect legitimate "idleness" will be
 fooled by a line dropped because some idiot buggy game hung up,
 too, so this is not a place for amateur hacks to be blindly
 applied, but that is a separate question.]

A very pertinent example today might be a raytracing routine;
run in foreground, it could sit for a day on a system as slow
as my home machine, churning bits to some disk file, without
a single keypress or character to the screen; nuking it on a
remote login because I'm "idle" is a fairly unfriendly act.

[Not that a site might not do that by policy to free up a
 line from a user to lazy to learn how to run a job
 disconnected from his/her sessiion; just another example.]

The autologout blunders I saw in the mid 70's need not be
repeated in the 90's, which is why I raised the question.

I still don't know if the code that started this thread is
in fact taking a careful look around before deciding to
nuke the user's session, I'm just promoting the idea of
taking that look first, in this and any other autologout
routines.  It is easy to do more harm than good with a
naive approach to this complicated problem.

Kent, the man from xanth.
<xanthian at Zorch.SF-Bay.ORG> <xanthian at well.sf.ca.us>