harold@ubvax.UUCP (Harold Cook) (07/13/85)
Does anyone have (or know of) a daemon which will monitor users idle time, and logout any user idle longer than a given amount of time. We have recently had troubles with too many people and not enough ports, especially when there are ports where people have left terminals for extended periods of time. Please respond via mail and as usual, I will summarize for the net. Many thanks in advance --
lcc.barry@UCLA-LOCUS.ARPA (Barry Gold) (07/17/85)
Does anyone have (or know of) a daemon which will monitor users idle time, and logout any user idle longer than a given amount of time. We have recently had troubles with too many people and not enough ports, especially when there are ports where people have left terminals for extended periods of time. DON'T DO IT. Try to educate your users to be more cooperative while you get more ports. If necessary, increase the charge for connect time. When users' supervisors/instructors start finding their budgets eaten up by connect time charges for idle time, the users will get the message fast! Maybe $100/hour :-) If you put in a daemon to monitor idle time, you'll just encourage your users to write programs that make their terminals appear non-idle. We had such a program at SDC and it believed any terminal i/o was non-idle, so I wrote a shell script that slept for 5 minutes and echoed a line to the terminal, ad infinitum. If you consider only input non-idle, people will echo character strings to their terminals that cause the terminals to send input (almost any crt, even "dumb" ones, will do that these days). The solution to inadequate computing resources is to get more resources. If you can't afford more resources, charge enough for your computing that you CAN get more resources. Please respond via mail and as usual, I will summarize for the net. Sorry, the digestification process doesn't leave a useful return address (moderator please note). The following from line is not acceptable to lcc (or ucla-cs, our arpanet relay) because they have no idea how to turn "ubvax.UUCP" into a useful path: From: harold@ubvax.UUCP (Harold Cook)
rbp@investor.UUCP (Bob Peirce) (07/17/85)
> Does anyone have (or know of) a daemon which will monitor users idle time, > and logout any user idle longer than a given amount of time. > Please respond via mail and as usual, I will summarize for the net. Sorry, I don't have a path to you, but this works on SYS III. I use it as part of my el-cheapo, one modem both ways set-up. Stick it in cron to run every once in a while. You may want to modify this to handle several lines. # -- ckmod # Robert B. Peirce; Cookson, Peirce & Co., Inc. # If anyone is inactive on a modem > $GRACE minutes log them off # This version gives no quarter. # Have to look for hung outgoing uucp stuff too. if [ $# -ne 1 ] then echo "usage: ckmod tty#" exit 1 fi MODEM=$1 GRACE=15 # minutes of no activity HM=/usr/lib/uucp LOG=/u/rbp/kill.log SPOOL=/usr/spool/uucp cd $HM # If set doesn't produce anything, force it. set `who | grep tty$MODEM || echo XXX` U=$1 if [ $U = XXX ] then U="" fi # Get current time set `date | tr ":" " "` M=$2 D=$3 HC=$4 MC=$5 # Get time device last accessed set `/usr/ucb/ls -l /dev/tty$MODEM | tr ":" " "` HL=$8 ML=$9 # Check for midnight crossover if [ $HL -gt $HC ] then HL=`expr $HL + 24` fi # Calculate time since last access of device TIME=`expr \( 60 "*" $HC + $MC \) - \( 60 "*" $HL + $ML \)` if [ $U ] then if [ $TIME -ge 1 ] then echo "$U tty$MODEM ($M $D $HC:$MC $HL:$ML) $TIME minutes.\c"\ >> $LOG if [ $TIME -lt $GRACE ] then echo >> $LOG fi fi if [ $TIME -ge $GRACE ] then # Let him have it P=`ps -ft$MODEM | awk 'BEGIN{FS=" "}/'$U'/{print $2;exit}'` if [ $P ] then kill -9 $P echo " Killed after $TIME minutes." >> $LOG else echo >> $LOG fi fi else # Nobody logged on from outside LCK=`ls $SPOOL | egrep "LCK\.\..|.lock"` # locks placed in uucp if [ "$LCK" -a $TIME -ge $GRACE ] # uucp has hung then cd $SPOOL rm -f $LCK fi fi -- Bob Peirce uucp: ...!{allegra, bellcore, cadre, idis} !pitt!darth!investor!rbp
rbp@investor.UUCP (Bob Peirce) (07/17/85)
> # -- ckmod > # Check for midnight crossover > if [ $HL -gt $HC ] > then > HL=`expr $HL + 24` > fi Peirce, you're an idiot. If HL is already greater than HC, adding 24 hours isn't going to help! Change that to HC=`expr $HC + 24`. Then, in the next calculation you have a shot at finding a time difference when midnight is overlapped. -- Bob Peirce uucp: ...!{allegra, bellcore, cadre, idis} !pitt!darth!investor!rbp
rsk@asc.purdue.edu (Wombat) (07/17/85)
> From: Barry Gold <lcc.barry@UCLA-LOCUS.ARPA> > DON'T DO IT. Try to educate your users to be more cooperative while you get > more ports. If necessary, increase the charge for connect time. In our environment, these are not viable alternatives; we are adding ports, and we have (in the past) increased the charge for connect time; neither has discouraged port-sitting. Therefore, we have such a daemon. > If you put in a daemon to monitor idle time, you'll just encourage your > users to write programs that make their terminals appear non-idle. 'Tis true. However, most users will not be so clever--we hope. In the case of those that are, 'we will find them, and we will kill them'.(1) > The solution to inadequate computing resources is to get more resources. > If you can't afford more resources, charge enough for your computing > that you CAN get more resources. Perhaps. Another solution is to make *intelligent* use of the resources one has; in our case, since we are a university computing center, it is clearly the preferred choice. I don't like the idea of using such a daemon; however, after much debate and discussion, we have concluded that it's the only way to solve our problem. It may be fascist, but it works. Rich Kulawiec Purdue University Computing Center (1) Saturday Night Live, 1984.
Crispin@SUMEX-AIM.ARPA (Mark Crispin) (07/18/85)
The best way to make users clever enough to defeat fascist
daemons is create such a daemon. It sounds to me like you have
bad communication with your user community. You do not need to
run a university computer center like the users are children.
You can treat them as responsible adults and involve them in
resource allocation policies.
Sometimes I think university computer centers with fascist
policies actually enjoy conflict with users. Only problem is,
with systems like Unix with more holes than Swiss cheese, sooner
or later the computer center will lose.
-------RSanders@USGS2-MULTICS.ARPA (07/18/85)
I've posted an updated version of "idlekill" to the ARPA side of net.sources. Idlekill works on 4.2 BSD VAXen and SUNs. In our community of ~180 scientists and technicians, no one has bothered to defeat this "daemon". Idlekill uses the idle times reported by "w", which looks at the time of last input, indirectly, by doing a stat on ttyXX for each logged-in user. The only trouble we've had with it so far is the occasional Bourne shell user who runs a long interactive-at-the-beginning program when the load average is high. Then we just "mv /etc/idlekill /etc/Idlekill" to turn it off for a while. -- Rex
chuqui@nsc.UUCP (Chuq Von Rospach) (07/20/85)
In article <11650@brl-tgr.ARPA> Crispin@SUMEX-AIM.ARPA (Mark Crispin) writes: > > The best way to make users clever enough to defeat fascist >daemons is create such a daemon. It sounds to me like you have >You do not need tobad communication with your user community. Well, here my problem is that I have three modems that are used by a wide variety of people in various places that get called to meetings, that get interrupted by the phone, and are generally trying to do 5 or 10 things at once. Occasionally they forget to log off or hang up their modem, and I lost one of those modems from use until I track it down and unplug it. None of this is fascist, just trying to free up forgotten resources because we have a large (and growing) community of users that need the modems. I need a daemon mainly to help people that sometimes forget in all honesty remember again. -- :From the carousel of the autumn carnival: Chuq Von Rospach {cbosgd,fortune,hplabs,ihnp4,seismo}!nsc!chuqui nsc!chuqui@decwrl.ARPA Your fifteen minutes are up. Please step aside!
cudcv@daisy.warwick.UUCP (Rob McMahon) (07/21/85)
<> We were also having trouble with people forgetting to log off, many of our users are fairly naive first year undergraduates. We modified `sh' and `csh' to prompt the user to hit return after 5 minutes of being idle, and log him off if he didn't respond within another 2.5 minutes. This has been working quite well for those who just forget, and protects them from the malicious people who come along and find them still logged in. The talk of daemons makes me worry - on our system you cannot tell from the modify time of the terminal whether a line is idle or not. While people are sitting in our favourite screen editor, they show up as idle to `w' and such how ever busily they are typing - one of those daemons are our machine would embarrass a lot of people! Does no one else have this feature ? I believe it is a feature of `cbreak', although I have not spent the time rummaging through the teletype driver to investigate. (We're running 4.2bsd on a VAX780) Rob McMahon, Computer Unit, Warwick University, UK UUCP: ...!mcvax!ukc!warwick!cudcv JANET: cudcv@uk.ac.warwk.daisy
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (07/22/85)
There is NO reliable way for the system to tell whether a user has wandered forgetfully away from his logged-in terminal or if he is in fact still using his connection. For example, at BRL we have quite a few Teletype 5620 DMDs (these are really nifty), and it is not at all out of the question for all interaction to be happening entirely within the DMD terminal itself for many minutes on end; yet the connection to the host must remain open for when it's needed. Our solution is to enable a TIMEOUT feature in the shell, and to set TIMEOUT=0 (disabled) in /etc/profile (or equivalent) when the user is found to be logging in on a 5620. This scheme protects against forgetful naive users without getting in the way of DMDs or knowledgeable users.
dhb@rayssd.UUCP (David H. Brierley) (07/23/85)
There is more than one reason possible for wanting (needing) to run an "idle time logout daemon". We have a fairly large user community competing for a limited number of ports on our machines and (in the past) would frequently find 5 or more users that had been idle for 30 minutes or more. Some of these people were intentionaly doing something to tie up the port and thus guarantee themselves a port for later, but a large majority of them simply got distracted from the terminal and forget to log off. If these people were then called on the phone and reminded that they had an idle terminal still logged in, more often than not they would log off. I am a firm believer in not doing something manually that the computer can do for me so I wrote a daemon that would check for idle logins and send the user a friendly message telling them that they were idle and to please log off. Since there is a possibility (high probability) that the user has actually left the office and is nowhere near the terminal, after three such messages (5 minutes apart) the daemon will drop carrier on the terminal line. The daemon goes to great lengths to determine if the user is really idle or is just running something that hasn't taken any input from the terminal in a while. As far as educating the users go, we also have an ongoing effort in that regard. Most of our users now remember to log off when they are done because they know they they get these "cute" reminders if they dont. By the way, did I mention that the daemon prints the login id and the length of time that they have been idle on the system console for all to see. If we notice a user intentionally doing something to make their terminal appear to not be idle, their login is locked out and they must have a heart-to-heart talk with the manger of operations in order to be allowed back on. They tend not to do this more than once. In the end, user education is probably the only legitimate route to take but a friendly idle time logout deamon can be effectively used as an educational tool. -- Dave Brierley Raytheon Co.; Portsmouth RI; (401)-847-8000 x4073 ...!decvax!brunix!rayssd!dhb ...!allegra!rayssd!dhb ...!linus!rayssd!dhb
kimery@wdl1.UUCP (Sam Kimery) (07/25/85)
> > > The talk of daemons makes me worry - on our system you cannot tell from the > modify time of the terminal whether a line is idle or not. While people > are sitting in our favourite screen editor, they show up as idle to `w' and > such how ever busily they are typing - one of those daemons are our machine > would embarrass a lot of people! Does no one else have this feature ? I > believe it is a feature of `cbreak', although I have not spent the time > rummaging through the teletype driver to investigate. > > (We're running 4.2bsd on a VAX780) > It is fairly simple to make the mods to both csh and sh to include and optional autologout feature (That could be installed as new accounts are added and owned by root to make it harder to remove.) The length of time can be set externally. This involves about 5 - 10 lines of code, and is much cleaner than a daemon. (but is contrary to the normal Un*x philosophy) This will also NOT log you out if you are not in the parent shell. (Of course this relies on how you program it). This means that you won't be knocked out of an editor, etc.) The way we are running we use the variable ILOG, set in the .cshrc files. (IE setenv ILOG 30, gives 30 minutes of idle time before autologout) Sam Kimery kimery@FORD-WDL1
chris@umcp-cs.UUCP (Chris Torek) (07/30/85)
>It is fairly simple to make the mods to both csh and sh to include and >optional autologout. [...] This means that you won't be knocked out of >an editor, etc.) As the author of a timeout daemon (who protested every line of the wretched thing), I have to point out that this is a bug for those who need timeouts. My timeout daemon gives one 3 warnings (at 15, 10, and 5 minutes before doom) then uses SIGHUP to kill things. This looks like a modem disconnect to most everything; editors save your editing and all that. Personally, I'd rather have 50 modems and leave idle connections alone, but. . . . -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@maryland