Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!wuarchive!zaphod.mps.ohio-state.edu!mips!wyse!vsi1!zorch!xanthian From: xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) Newsgroups: alt.sources.d Subject: Re: v11i020: Idle demon Message-ID: <1990Aug24.121314.154@zorch.SF-Bay.ORG> Date: 24 Aug 90 12:13:14 GMT References: <1990Aug23.143804.24954@ux1.cso.uiuc.edu> Organization: SF Bay Public-Access Unix Lines: 71 [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@abcfd01.larc.nasa.gov (Tad Guy) writes: >peltz@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.