tong@rscene.hac.com (Kevin Tong) (09/12/90)
Does anyone out there know of any software that will log out users after a certain amount of idle time? We have only a limited number of ports and some users stay logged on even after they leave. Thanks. ************************************************************************ Kevin Tong, (213) 513-3882 Hughes Aircraft Company tong@rscene.hac.com Long Beach, CA 90810 ************************************************************************
aem@mthvax.cs.miami.edu (a.e.mossberg) (09/14/90)
In <10504@hacgate.UUCP> tong@rscene.hac.com (Kevin Tong) writes: >Does anyone out there know of any software that will >log out users after a certain amount of idle time? >We have only a limited number of ports and some >users stay logged on even after they leave. I use untamo, which I got long long ago. I'm not sure where I got the one I run now, but it is not the same that appeared in comp.source.(misc? unix?). It is available from mthvax.cs.miami.edu via ftp as ~ftp/pub/untamo.shar.Z or by the netlib server netlib@mthvax.cs.miami.edu by sending it the request: send untamo.shar from sources aem -- a.e.mossberg / aem@mthvax.cs.miami.edu / aem@umiami.BITNET / Pahayokee Bioregion Historic responsibility has to make up for the want of legal responsibility. Power tends to corrupt, and absolute power corrupts absolutely. Lord Acton
eugen@hpbbi4.BBN.HP.COM (#Eugen Bauknecht) (10/01/90)
I am using a script which I called " killuser " and which is started by cron
every 10 minutes or so.
Hope this helps
===================================================================
# killuser
# kills all users, whose processes are idle longer than 1 hour.
who -u | awk '{print $2,$6}' > /tmp/kltmp0
cat /tmp/kltmp0 | awk '{ if ($2>=1) print $1 }' >> /tmp/kltmp1
var=`cat /tmp/kltmp1` ;export var
for i in $var
do
ps -ft $i >> /tmp/kltmp2
done
cat /tmp/kltmp2 2>/dev/null| awk '{if ($2 !="PID") print $2}' >>/tmp/kltmp3
sort -rn -o/tmp/kltmp4 /tmp/kltmp3
var=`cat /tmp/kltmp4`
kill -9 `echo $var` 2>/dev/null
rm /tmp/kltmp* 2>/dev/null
#endcudcv@warwick.ac.uk (Rob McMahon) (10/04/90)
I'm guessing a bit at this script, because it's full of SystemV-ism's, and this article is not about critising code, but ... In article <9800001@hpbbi4.BBN.HP.COM> eugen@hpbbi4.BBN.HP.COM (#Eugen Bauknecht) writes: >who -u | awk '{print $2,$6}' > /tmp/kltmp0 (Sorry what's who -u ? Is this a System-V ism ? I'll assume $2 is the terminal, and $6 is the `idle time', got by checking the mtime & atime of the tty). >cat /tmp/kltmp0 | awk '{ if ($2>=1) print $1 }' >> /tmp/kltmp1 >var=`cat /tmp/kltmp1` ;export var >for i in $var (I don't get this, what's wrong with "for i in `cat /tmp/kltmp1`" ? Why export $var ?) > do > ps -ft $i >> /tmp/kltmp2 >done (I don't actually know what -ft is either, I'll assume it prints out the processes attached to some terminal specified by the t option, in some format specified by the f option.) >cat /tmp/kltmp2 2>/dev/null| awk '{if ($2 !="PID") print $2}' >>/tmp/kltmp3 >sort -rn -o/tmp/kltmp4 /tmp/kltmp3 >var=`cat /tmp/kltmp4` >kill -9 `echo $var` 2>/dev/null (Weird, what's wrong with kill -9 `cat /tmp/kltmp4` ? ) Aaagh! Please don't just `kill -9' at least do a `kill -1' first, maybe followed a few seconds later by a plain `kill' before getting that drastic. Preferably send the process group of the terminal a SIGHUP, and then just kill the shell if it doesn't go away of it's own accord. 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: I can assure you I was typing at this editor just 2 minutes ago: Script started on Thu Oct 4 14:37:27 1990 cudcv (41) >> w 2:37pm up 6 days, 6:56, 26 users, load average: 1.28, 0.48, 0.47 User tty login@ idle JCPU PCPU what root console 7:32am 6:45 2:24 40 -csh ... cudcv ttyq6 2:10pm 27 1 ded xx ... cudcv (42) >> sps vt q6 Ty User Status Fl Nice Virt Res %M Time Child %C Proc# Command q6 cudcv pause 248 0 0 1.4+ 1.3 0 20328 -tcsh q6. * rttyq6 80 0 0 0.1 0 20345 ded xx 154 (13488k) processes, 1 (624k) busy, 57 (8072k) loaded, 96 (16952k) swapped cudcv (43) >> pstat -p 154/1034 processes LOC S F PRI SIG UID SLP TIM CPU NI PGRP PID PPID RSS SRSS SIZE WCHAN LINK ... f8197824 1 8000 28 0 60 127 25 0 20 20345 20345 20328 0 8 a ff14be20 f8195858 ... f8198164 1 8200 40 0 60 127 127 29 20 20328 20328 20327 0 29 1f ffffc000 f819872c ... cudcv (44) >> x exit script done on Thu Oct 4 14:38:06 1990 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). Rob -- UUCP: ...!mcsun!ukc!warwick!cudcv PHONE: +44 203 523037 JANET: cudcv@uk.ac.warwick INET: cudcv@warwick.ac.uk Rob McMahon, Computing Services, Warwick University, Coventry CV4 7AL, England
james@dlss2.UUCP (James Cummings) (10/05/90)
In article <1990Oct4.135333.19139@warwick.ac.uk> cudcv@warwick.ac.uk (Rob McMahon) writes: >I'm guessing a bit at this script, because it's full of SystemV-ism's, and >this article is not about critising code, but ... > >In article <9800001@hpbbi4.BBN.HP.COM> eugen@hpbbi4.BBN.HP.COM (#Eugen Bauknecht) writes: >>who -u | awk '{print $2,$6}' > /tmp/kltmp0 > >(Sorry what's who -u ? Is this a System-V ism ? I'll assume $2 is the >terminal, and $6 is the `idle time', got by checking the mtime & atime of the >tty). who -u is a shell method of finding not only who is on, but the amount of "idle" time and their process id, etc. System-V ism?? could be but I believe I've seen it on other systems also, not all but (again I think) some BSDs (newer versions maybe?). At anyrate it is NOT a sure fire way to gauge "idleness". I wrote, and haven't finished smoothing out some of the edges on, a C implementation that looks directly at the utmp file for struct utmp.ut_type equal to "7"(a USER_PROCESS) and guages time by calling stat() against the utmp.ut_line (tty line) for last modified time. As I understand it, the who -u shell command can be fooled(fact) by even a loop which echos a bell character to the screen, but this method requires(?) keyboard input to change the modify time. Systems that do not support the utmp file or don't allow access to it would have to take a totally different approach. I'd be interested, just for the knowledge, to know how this would be implemented without a utmp.
jiml@uwslh.slh.wisc.edu (James E. Leinweber) (10/11/90)
james@dlss2.UUCP (James Cummings) writes: >I wrote, and haven't finished smoothing out some >of the edges on, a C implementation that looks directly at the utmp file >for struct utmp.ut_type equal to "7"(a USER_PROCESS) and guages time by >calling stat() against the utmp.ut_line (tty line) for last modified time. Utmp and the actual terminal line aren't always a good judge of idleness. We run the "assassin" program (BSD systems only, posted a few years ago) here, and we had to tell it to ignore kermit. Our version of kermit opens /dev/tty for its I/O, and a furiously active transfer of a large file looks quite idle by any easy measure except CPU activity. I have grave doubts that there is any general way of distinguishing idle users from unusual ones, at least in environments with distributed computations containing delays. A typical thing here is to start a kermit session between two minicomputers, with the local end idle while the remote end generates the file to be transfered, followed by the transfer. If anyone can tell me how to tell that from an idle user, I'd be amazed. -- Jim Leinweber (608)262-0736 State Lab. of Hygiene/U. of Wisconsin - Madison jiml@sente.slh.wisc.edu uunet!uwvax!uwslh!jiml fax:(608)262-3257
dan@sci.ccny.cuny.edu (Dan Schlitt) (10/11/90)
In article <1990Oct4.135333.19139@warwick.ac.uk> cudcv@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@sci.ccny.cuny.edu City College of New York dan@ccnysci.uucp New York, NY 10031 dan@ccnysci.bitnet (212)650-7885
FFAAC09@cc1.kuleuven.ac.be (Nicole Delbecque & Paul Bijnens) (10/11/90)
>>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 jus >> ... >>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: >... >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. If you don't have sources, this little Bourne-shell program, called "alive" can help sometimes (execute it from the /dev/tty??? in question): # alive -- give signes of life on this terminal if [ -z "$MYTTY" ] then # fork into the background cd / MYTTY=`tty`; export MYTTY nice -19 $0 $* & exit 0 fi while touch -m $MYTTY do sleep ${1:-3600} done > 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. Yes, a good advice: if you want to run that idle-killer, give it a real long permitted idle-time, or don't run it at all. -- Polleke
craig@attcan.UUCP (Craig Campbell) (10/13/90)
James, I tried to mail you this response, but it bounced. This may be of interest to you since you seem to be working on an idle user watchdog on a SYS-V unix. (Hope so...) In article <94@ dlss2.UUCP> you write: In article <1990Oct4.135333.19139@warwick.ac.uk> cudcv@warwick.ac.uk (Rob McMahon) writes: I'm guessing a bit at this script, because it's full of SystemV-ism's, and this article is not about critising code, but ... In article <9800001@hpbbi4.BBN.HP.COM> eugen@hpbbi4.BBN.HP.COM (#Eugen Bauknecht) writes: who -u | awk '{print $2,$6}' > /tmp/kltmp0 (Sorry what's who -u ? Is this a System-V ism ? I'll assume $2 is the terminal, and $6 is the `idle time', got by checking the mtime & atime of the tty). who -u is a shell method of finding not only who is on, but the amount of "idle" time and their process id, etc. System-V ism?? could be but I believe I've seen it on other systems also, not all but (again I think) some BSDs (newer versions maybe?). At anyrate it is NOT a sure fire way to gauge "idleness". I wrote, and haven't finished smoothing out some of the edges on, a C implementation that looks directly at the utmp file for struct utmp.ut_type equal to "7"(a USER_PROCESS) and guages time by calling stat() against the utmp.ut_line (tty line) for last modified time. As I understand it, the who -u shell command can be fooled(fact) by even a loop which echos a bell character to the screen, but this method requires(?) keyboard input to change the modify time. Systems that do not support the utmp file or don't allow access to it would have to take a totally different approach. I'd be interested, just for the knowledge, to know how this would be implemented without a utmp. Are you familiar with layers? This product has the side effect of making a terminal appear idle when it is not. Layers changes your tty device to something of the form /dev/xt??# where #={1,2,3,4,5,6,7}. Who will indicate that you are (by default) logged into /dev/xt??1. This can be changed, but the problem remains that you have 7 potential windows, each of which is a valid "terminal" which may be in use. If you log off the user on the /dev/tty?? device, layers will be killed, all the users windows will fail, and the terminal will probably need to a hard-reset. If you are unfamiliar with layers, please feel free to contact me and I will forward you any useful info I can. I beleive your auto log off program can account for layers (if it doesn't already). Good luck, craig
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (10/18/90)
In article <1990Oct10.180836.12313@sci.ccny.cuny.edu> dan@sci.ccny.cuny.edu (Dan Schlitt) writes: > 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. That's wrong in two ways. One is that I might want to leave a csh running while I work at another shell. Two is that a user who leaves his terminal with an editor running has left it completely open. Those who say that idle daemons are impossible to do well have not learned to distinguish between sessions and connections. An idle daemon is something to cut short an idle *connection*. If you are connected to a session running a window manager that uses several ttys, what should the idle daemon kill? Each individual tty? Of course not. It's an idle *connection*, not an idle session, that's dangerous. ---Dan
de5@ornl.gov (Dave Sill) (10/18/90)
In article <11077:Oct1721:21:2390@kramden.acf.nyu.edu>, brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: > >Those who say that idle daemons are impossible to do well have not >learned to distinguish between sessions and connections. An idle daemon >is something to cut short an idle *connection*. If you are connected to >a session running a window manager that uses several ttys, what should >the idle daemon kill? Each individual tty? Of course not. It's an idle >*connection*, not an idle session, that's dangerous. I don't think it's as simple as that, Dan. If I'm sitting on my workstation with active xterms to various systems, what's dangerous about one or more of those connections being idle? Isn't it really an *unattended* connection that's dangerous? Idleness is just a kludge for detecting the presence of an individual, and killing idle connections is a kludge for re-validating them. Ideally, my workstation would monitor my presence and disable input and output during periods of my absence. Realistically, a mechanism which would activate xlock--or equivalent--after some timeout period would acceptable. But to work well, the systems I'm connected to would have to know that idleness on my connections to them is OK, unlike connections from terminals or devices without such a mechanism. So, the way I see it, idle daemons may not be *impossible*, but they sure are nontrivial. And I have yet to see one that works right. -- Dave Sill (de5@ornl.gov) Martin Marietta Energy Systems Workstation Support
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (10/19/90)
In article <1990Oct18.135619.2393@cs.utk.edu> Dave Sill <de5@ornl.gov> writes: > I don't think it's as simple as that, Dan. If I'm sitting on my > workstation with active xterms to various systems, what's dangerous > about one or more of those connections being idle? Hm? Nothing at all. It's the client's responsibility to handle timeouts. The client knows if it's sitting under an already idle-protected session and can behave appropriately. I imagine a TELNET option like ``WILL IDLE'' telling the server that the client can handle timeouts. The server will only bother handling idle if the option isn't negotiated. Your xterm client will negotiate it. ---Dan