bengsig@orcenl.uucp (Bjorn Engsig) (11/23/88)
Is there any way to see if a terminal has not been used for some time, and if it hasn't, to send a hangup to the processes there? We are looking for a system that is usable on all flavors and variants of unix, including SystemV, BSD, AIX, HP-UX, etc. etc., but if somebody has some idea or even sources for a particular system, it is mostly welcome as well. The mechanism should NOT depend on the use of a particular shell. -- Bjorn Engsig, ORACLE Europe \ / "Hofstaedter's Law: It always takes ..!uunet!mcvax!orcenl!bengsig X longer than you expect, even if you phone: +31 21 59 56 411 / \ take into account Hofstaedter's Law"
gwyn@smoke.BRL.MIL (Doug Gwyn ) (11/24/88)
In article <201.nlunix6@orcenl.uucp> bengsig@orcenl.uucp (Bjorn Engsig) writes: >Is there any way to see if a terminal has not been used for some time, >and if it hasn't, to send a hangup to the processes there? Try that around here and you may get stomped on! Just why this is a BAD idea has been spelled out many times before and need not be repeated.
jpr@dasys1.UUCP (Jean-Pierre Radley) (11/25/88)
In article <201.nlunix6@orcenl.uucp> bengsig@orcenl.uucp (Bjorn Engsig) writes: >Is there any way to see if a terminal has not been used for some time, >and if it hasn't, to send a hangup to the processes there? Xenix for the Tandy 6000 series, which is a composite product of Microsoft, Tandy, and SCO, has a program called /usr/lib/idle, designed to be run by cron (reading settings in /etc/default/idle) to "log idle users off". This program was written by Tandy, and I doubt if they'll release source. Try putting a note in comp.sys.tandy, it is monitored by some of the techies at Tandy headquarters. -- Jean-Pierre Radley Honi soit jpr@dasys1.UUCP New York, New York qui mal ...!hombre!jpradley!jpr CIS: 76120,1341 y pense ...!hombre!trigere!jpr
holgi@sns.UUCP (Holger Kollmer) (11/25/88)
In article <201.nlunix6@orcenl.uucp> bengsig@orcenl.uucp (Bjorn Engsig) writes: >Is there any way to see if a terminal has not been used for some time, >and if it hasn't, to send a hangup to the processes there? We are looking You can make stat(2) on the tty. That system call returns st_mtime and st_atime which shows the last access and modification time. -- Holger Kollmer uucp: uunet!mcvax!unido!sns!holgi "Document UN*X, Are You Kidding ?"
eap@bu-cs.BU.EDU (Eric Pearce) (11/26/88)
In article <8978@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) says: >In article <201.nlunix6@orcenl.uucp> bengsig@orcenl.uucp (Bjorn Engsig) writes: >>Is there any way to see if a terminal has not been used for some time, >>and if it hasn't, to send a hangup to the processes there? > >Try that around here and you may get stomped on! > >Just why this is a BAD idea has been spelled out many times before >and need not be repeated. I think there is a program called 'untamo' in one of those comp.sources.unix archives. It prints a warning on the idle terminal and then kills them off if they remain idle. You could easily modify it to have an exception list of terminals to ignore. This could be useful in an environment such as a university, where you have a 'terminal room' with people fighting over a small number of terminals. -e -- ------------------------------------------------------------------------------- UUCP !harvard!bu-cs!bu-it!eap ARPANET eap@bu-it.bu.edu CSNET eap%bu-it@bu-cs JNET jnet%"ep@buenga" BITNET iteap@buacca or ep@buenga
jay@mentor.cc.purdue.edu (Jay Vosburgh) (11/27/88)
In article <26258@bu-cs.BU.EDU>, eap@bu-cs (Eric Pearce) writes: > > I think there is a program called 'untamo' in one of those comp.sources.unix > archives. It prints a warning on the idle terminal and then kills them off > if they remain idle. You could easily modify it to have an exception list of > terminals to ignore. > The version of untamo in the archives is very out of date; the latest version is available via anonymous ftp from j.cc.purdue.edu in pub/untamo.shar. The version there dates from about 6 months ago. A new release has been in the works for some time, hopefully I'll be able to really get it out in a month or two. Also, please send any and all untamo-related mail to untamo@j.cc.purdue.edu, this will get you to the right person right away. -J (Current maintainer of untamo) ----- Jay "Fubar" Vosburgh Purdue University Computing Center Unix Group jay@mentor.cc.purdue.edu, mentor.cc.purdue.edu!jay, FUBAR@PURCCVM
connet@castor.usc.edu (David Connet) (11/28/88)
In article <201.nlunix6@orcenl.uucp> bengsig@orcenl.uucp (Bjorn Engsig) writes: >Is there any way to see if a terminal has not been used for some time, >and if it hasn't, to send a hangup to the processes there? We are looking Another way, if you are using ksh, is to set the TMOUT variable. After TMOUT seconds, a message is sent saying to the effect 'if you don't do something in 60 seconds, I'm killing you...' Dave Connet
gwyn@smoke.BRL.MIL (Doug Gwyn ) (11/28/88)
In article <2018@nunki.usc.edu> connet@castor.usc.edu (David Connet) writes: >Another way, if you are using ksh, is to set the TMOUT variable. >After TMOUT seconds, a message is sent saying to the effect 'if you don't >do something in 60 seconds, I'm killing you...' I don't know why Korn chose TMOUT when TIMEOUT was the prior art for this. The BRL Bourne shell also can optionally be configured with TIMEOUT support. The correct description is: If a PS1 prompt is not responded to within the TIMEOUT period, the shell exits. Setting TIMEOUT to 0 disables this feature. Note that Blit/DMD/MTG (5620/630 etc.) users have to disable TIMEOUT since some of their layer windows may not receive any input for quite some time, especially if a downloaded process is in control of the layer. At least with the TIMEOUT approach there IS a way to disable the auto-timeout when necessary. Most suggested approaches are just not usable in any but the most mickey-mouse environments.
dtynan@sultra.UUCP (Der Tynan) (11/29/88)
In article <201.nlunix6@orcenl.uucp> bengsig@orcenl.uucp (Bjorn Engsig) writes: >Is there any way to see if a terminal has not been used for some time, >and if it hasn't, to send a hangup to the processes there? Look for dust on the keyboard. That's an obvious sign :-) Seriously though, I've seen at least three such programs posted to comp.sources. A quick check through the UUNET archives shows ~ftp/comp.sources.unix/volume3/idledaemon.Z If you don't have access to a c.s.u archive, let me know, and I'll send you the 'shar' file. In article <8978@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn ) writes: > Try that around here and you may get stomped on! > > Just why this is a BAD idea has been spelled out many times before > and need not be repeated. Hmm, Doug. I don't think he was asking whether or not it was a good idea. All he wants is the software. Anyway, I don't mind if you spell it out one more time. I'd like to know why it is better to leave Joe User's account available for a passer-by, than to kill it. A lot of UN*X sites I've seen have a lot of users who leave themselves logged in, indefinitely. In fact, the only time they actually log in, is after the system has crashed! I guess it's paranoia that the boss actually audits the accounting files, to see what time they got in at :-). Anyway, perhaps you'd like to let me know why it's such a terrible sin to kill these jobs. - Der -- dtynan@zorba.Tynan.COM (Dermot Tynan @ Tynan Computers) {apple,mips,pyramid,uunet}!Tynan.COM!dtynan --- If the Law is for the People, then why do we need Lawyers? ---
steve@obed.uucp (stephen Samuel) (11/29/88)
In article <201.nlunix6@orcenl.uucp>, bengsig@orcenl.uucp (Bjorn Engsig) writes: > Is there any way to see if a terminal has not been used for some time, > ... We are looking for a system that is usable on all flavors and variants > of unix, .... I wrote a program that I call 'vulture'. It is written in C, and rips apart the output from 'ps' to get the info it needs. The program takes parameters that include the TTY to be watched, how long it can be idle for, and how often to check. -- Stephen samuel !alberta!{obed,edm}!steve Look on the bright side... It might have worked!
gwyn@smoke.BRL.MIL (Doug Gwyn ) (11/29/88)
In article <2682@sultra.UUCP> dtynan@sultra.UUCP (Der Tynan) writes: >Anyway, perhaps you'd like to let me know >why it's such a terrible sin to kill these jobs. Because any automated scheme you come up is likely to ALSO kill off some perfectly legitimate jobs. I have, nearly every day, important connections between a "terminal" and a host computer that appear to have no activity on them for a long time, sometimes hours. However, the connections are needed and cannot be opened only at the time they are active; they must be arranged in advance then just sit there. An automatic "kill idle terminal" daemon would wreak havoc with this. There are many ways to deal with careless terminal users other than automatic idle-terminal killer software.
jbayer@ispi.UUCP (Jonathan Bayer) (11/29/88)
In article <8978@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn ) writes: > In article <201.nlunix6@orcenl.uucp> bengsig@orcenl.uucp (Bjorn Engsig) writes: > >Is there any way to see if a terminal has not been used for some time, > >and if it hasn't, to send a hangup to the processes there? > > Try that around here and you may get stomped on! > > Just why this is a BAD idea has been spelled out many times before > and need not be repeated. There are several scenerios in which you would want to kill an idle terminal. One is in a university/college environment which has somewhat limited resources. You would want to kill certain terminals which have been idle, while leaving others alive (leave the console alone, kill the students terminals after a certain time period). Another is in a commercial environment which has terminals in an open environment. A terminal which is idle with no one there is open to anybody sitting down and either changing the password, setting a trap, or some other deviltry. One of our products is called the Idle Killer, which does the above, and much more. For more info contact me via e-mail. Jonathan Bayer Intelligent Software Products, Inc.
bengsig@orcenl.uucp (Bjorn Engsig) (11/29/88)
In article <201.nlunix6@orcenl.uucp>, I asked > Is there any way to see if a terminal has not been used for some time, [ ... ] Thank you to all of you who send me a mail, or posted a followup. I've got plenty of ideas and pointers to existing software. Now, we can all just watch the ongoing discussion, whether one should have such a mechanism in the first place :-) -- Bjorn Engsig, ORACLE Europe \ / "Hofstaedter's Law: It always takes ..!uunet!mcvax!orcenl!bengsig X longer than you expect, even if you phone: +31 21 59 56 411 / \ take into account Hofstaedter's Law"
cdold@starfish.Convergent.COM (Clarence Dold) (11/30/88)
From article <2682@sultra.UUCP>, by dtynan@sultra.UUCP (Der Tynan): > All he wants is the software. Anyway, I don't mind if you spell it out > one more time. I'd like to know why it is better to leave Joe User's > account available for a passer-by, than to kill it. A lot of UN*X sites To back up my system, I do an su, followed by /etc/backup&, then exit. As long as I stay logged in as a normal user, the script continues. If I log out, the script is aborted. I don't leave a terminal in SuperUser lying around, even running a script. -- Clarence A Dold - cdold@starfish.Convergent.COM (408) 434-2083 ...pyramid!ctnews!professo!dold MailStop 18-011 P.O.Box 6685, San Jose, CA 95150-6685
lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) (11/30/88)
Doug Gwyn writes:
: Because any automated scheme you come up is likely to ALSO kill off
: some perfectly legitimate jobs.
Not only that, but idle-killers are so easy to spoof, unless you disable
people from executing utime() or ioctl().
Larry Wall
lwall@jpl-devvax.jpl.nasa.govbengsig@orcenl.uucp (Bjorn Engsig) (11/30/88)
In article <9012@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn ) writes: > >why it's such a terrible sin to kill these jobs. > > Because any automated scheme you come up is likely to ALSO kill off > some perfectly legitimate jobs. > What I asked for in the first place was just a program to send SIGHUP to processes, which seemed to be doing nothing. There will of course always be cases where this 'seems' is wrong, but a process that wants to live could easily do signal(SIGHUP,handler) (or nohup). When doing this, you show that you are aware of the possible 'auto-killing', and you will be sure not to be killed. This is also a nice thing to do on a modem line. -- Bjorn Engsig, ORACLE Europe \ / "Hofstaedter's Law: It always takes ..!uunet!mcvax!orcenl!bengsig X longer than you expect, even if you phone: +31 21 59 56 411 / \ take into account Hofstaedter's Law"
amos@taux02.UUCP (Amos Shapir) (11/30/88)
In article <9012@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >There are many ways to deal with careless terminal users other than >automatic idle-terminal killer software. Here's one: the following command file, for BSD systems, uses the output of 'w' to mail notes to idle users. The only bug is that such users are usually not there to read their mail... #!/bin/sh w -hs | \ sed -n 's/^\(.........\)\(..\)\(.[0-9]\).*/(echo You have a login session on tty\2\ echo which has been inactive for more than \3 days now. \ echo You can use ps -ut\2 to find out what processes run there and kill them.) \\\ |Mail -s "Idle login session" \1/p' |sh -- Amos Shapir amos@nsc.com National Semiconductor (Israel) P.O.B. 3007, Herzlia 46104, Israel Tel. +972 52 522261 TWX: 33691, fax: +972-52-558322 34 48 E / 32 10 N (My other cpu is a NS32532)
vch@attibr.UUCP (Vincent C. Hatem) (11/30/88)
In article <83@cosmic.sns.UUCP>, holgi@sns.UUCP (Holger Kollmer) writes: # In article <201.nlunix6@orcenl.uucp> bengsig@orcenl.uucp (Bjorn Engsig) writes: # #Is there any way to see if a terminal has not been used for some time, # #and if it hasn't, to send a hangup to the processes there? We are looking # # You can make stat(2) on the tty. That system call returns st_mtime and # st_atime which shows the last access and modification time. You could also use 'who -u' (on Sys V), which tells the idle time... -- Vincent C. Hatem | att ---->\ (available from any AT&T International | ulysses ->\ Action Central site) International Operations Technical Support | bellcore ->\___ !attibr!vch 1200 Mt Kemble Ave, Basking Ridge, NJ 07920 | (201) 953-8030
mchinni@ardec.arpa (Michael J. Chinni, SMCAR-CCS-E) (12/01/88)
Doug Gwyn writes: > There are many ways to deal with careless terminal users other than > automatic idle-terminal killer software. Like what? How else can you deal with the problem of careless terminal users at the time they are being careless? Of course, you could have the system admin. staff monitor the system and manually kill such idle terminal sessions. This however is cumbersome given several systems with large user populations and small system admin. staffs. ()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()() X X / \ / \ | | | | Michael J. Chinni || | | || |||| | | |||| US Army Armament Research, Development, /\ |||||| | | |||||| /\ and Engineering Center || |||||||| | | |||||||| || |||||+---+|| | | ||+---+||||| Picatinny Arsenal, New Jersey ||||||\./||| | | |||\./|||||| ||||||.X.||| | | |||.X.|||||| ||||||/.\||| | | |||/.\|||||| ARPA: mchinni@ardec.arpa ||---+---+-| | | |-+---+---|| UUCP: ...!uunet!ardec.arpa!mchinni || ||||||| | | | | ||||||| || AT&T: 201-724-4140 ++ +-+ +-+ ++ ()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()
gwyn@BRL.MIL (VLD/VMB) (12/01/88)
Use your imagination! For example: Announce to your users that there has been a problem with people leaving terminals unattended, and that you have set up a command "reward" that can be invoked ON THE OFFENDING TERMINAL by anyone who finds an unattended terminal logged in. The command would ask for the name of the snitch (and would automatically find the name of the offending user) and would mail the information to a system administrator. A small reward would be quietly given to the snitch and administrative action (perhaps a fine) would be taken against the offender. Then the TMOUT (or TIMEOUT) feature has already been mentioned; it provides a much better controlled way to terminate forgotten terminal connections, and has the important feature that IT CAN BE DISABLED by the user who knows that it would cause him problems.
cml@brachiosaur.cis.ohio-state.edu (Christopher Lott) (12/01/88)
In article <3603@jpl-devvax.JPL.NASA.GOV> lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) writes: >Not only that, but idle-killers are so easy to spoof, unless you disable >people from executing utime() or ioctl(). >Larry Wall >lwall@jpl-devvax.jpl.nasa.gov Well, yes. A friend (Hi, Ed) did so once; was nothing more than writing a little daemon to spit out a newline character using a 4.2BSD ioctl() call every IDLE_TIMEOUT_PERIOD - 1 minutes. But the reason I have put untamo, from Purdue cc, on our largish timeshare machine here was to free up precious hardwire lines to the campus network switch. Allows more people to have access. I maintain that people are slightly flaky at times (me especially) and do forget to log out - so a daemon that cleans up after them is more of a help than a detriment to the sysadmin effort. Putting the daemon to work is not a battle between the stodgy sysadmin and the clever, crafty user but merely another effort to allocate resources more fairly. [ Untamo allows nice exceptions - we never time-out a user on a pty, only on a hardwire line. My xterm client on that machine tends to go idle for long periods, but pseudo terminals are relatively cheap, so it's ok. ] I have no affiliation with untamo and authors except as a user. chris... -=- cml@tut.cis.ohio-state.edu Computer Science Department, OSU 614-292-6546 or: ...!{att,pyramid,killer}!osu-cis!cml <standard disclaimers>
dlp@gistdev.UUCP (12/01/88)
I wrote a routine for a customer to watch for idle terminals and kill them if they were inactive for longer than N minutes. People who were logged off by this routine received mail to that effect. A few days after the program was installed, many people had this in their .profile files: while sleep 55 do cat /dev/null >> /dev/tty done & Other people had routines to download a text file to their PCs, start up their favorite editor, and upload the file when they were finished editiing. Some of these people did not have the dirty trick in their .profile files, and discovered that they had lost half an hour's editing by being "inactive". On the whole, I think it was a BAD idea. Dirk Pellett -- standard disclaimers apply.
les@chinet.chi.il.us (Leslie Mikesell) (12/01/88)
In article <826@starfish.Convergent.COM> cdold@starfish.Convergent.COM (Clarence Dold) writes: >To back up my system, I do an su, followed by /etc/backup&, then exit. >As long as I stay logged in as a normal user, the script continues. >If I log out, the script is aborted. SysV has nohup to allow logging out without killing the running program: nohup /etc/backup & Some versions automatically redirect output to nohup.out if it is not otherwise redirected from the terminal. Or you could use "at now" which will mail any output to you. Neither is very useful if there is any chance that you will be prompted for new media. Les Mikesell
ag@elgar.UUCP (Keith Gabryelski) (12/01/88)
In article <74@attibr.UUCP> vch@attibr.UUCP (Vincent C. Hatem) writes: >You could also use 'who -u' (on Sys V), which tells the idle time... Idle time messages on some versions of system V who are broken. They use st_mtime instead of st_atime. From `man stat': sed -n "s/(S)/(2)/gp" # if appropriate. st_atime Time when file data was last accessed. Changed by the following system calls: creat(S), mknod(S), pipe(S), utime(S), and read(S). ^^^^^^^ st_mtime Time when data was last modified. Changed by the following system calls: creat(S), mknod(S), pipe(S), utime(S), and write(S). ^^^^^^^^ The idle daemon code is trivial (written during halftime on Monday). If anyone would like a copy, send me mail. In article <3603@jpl-devvax.JPL.NASA.GOV> lwall@jpl-devvax.jpl.nasa.gov (Larry Wall) brings up: >[...] but idle-killers are so easy to spoof, unless you disable >people from executing utime() or ioctl(). The daemon code, IMHO, should not be intended for use against malicious(*) or unwilling idlers. The code is used to logout users who forget to logout. Also, an idle daemon may not be appropriate for some (even most) sites, but it is a valid option for a few. You don't even have to be fascist about the code, set it for three hours if you like ... with warning messages. (*) ``malicious idlers'' here is defined as a user that hogs a terminal (by being logged in) for an usually long period of time without using the terminal. nohup(1) is a viable alternative in a lot of the idle terminal cases. Pax, Keith -- ag@elgar.CTS.COM Keith Gabryelski ...!{ucsd, jack}!elgar!ag
rbj@nav.icst.nbs.gov (Root Boy Jim) (12/02/88)
? From: "Michael J. Chinni, SMCAR-CCS-E" <mchinni@ardec.arpa>
? Doug Gwyn writes:
? > There are many ways to deal with careless terminal users other than
? > automatic idle-terminal killer software.
? Like what? How else can you deal with the problem of careless terminal
? users at the time they are being careless?
Depends on how evil you want to be. Some terminals have a screensaver
that blanks the screen after awhile. Any key press restores it. I used
to blindly hit return, but now hit shift instead (or space on terminals
that only unblank on a real key). Type `rm -rf ~' without the return.
If he or someone else hits return, well he is not a happy camper. That
is a bit severe, and could get you into trouble, so you might want to
change the -rf to -ri, or add an unmatched quote to scare him a bit.
Perhaps the best thing to do is put `kill -9 $$' or `exit' into his
.cshrc or .profile and then log him out, or chmod all his files to
mode 0 or change his shell, or as Doug says, use your imagination!
? ||||||/.\||| | | |||/.\|||||| ARPA: mchinni@ardec.arpa
? ||---+---+-| | | |-+---+---|| UUCP: ...!uunet!ardec.arpa!mchinni
? || ||||||| | | | | ||||||| || AT&T: 201-724-4140
Your signature is too long (most of it deleted).
(Root Boy) Jim Cottrell (301) 975-5688
<rbj@nav.icst.nbs.gov> or <rbj@icst-cmr.arpa>
Crackers and Worms -- Breakfast of Champions!gwyn@smoke.BRL.MIL (Doug Gwyn ) (12/02/88)
In article <213.nlunix6@orcenl.uucp> bengsig@orcenl.uucp (Bjorn Engsig) writes:
-What I asked for in the first place was just a program to send SIGHUP to
-processes, which seemed to be doing nothing. There will of course always
-be cases where this 'seems' is wrong, but a process that wants to live could
-easily do signal(SIGHUP,handler) (or nohup).
Sorry, this doesn't work right, and anyway why should a process have to
disable SIGHUP in order to do its natural job?jlh@loral.UUCP (Physically Pffft) (12/02/88)
In article <3603@jpl-devvax.JPL.NASA.GOV> lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) writes: >Not only that, but idle-killers are so easy to spoof, unless you disable >people from executing utime() or ioctl(). >Larry Wall >lwall@jpl-devvax.jpl.nasa.gov Hmmm, mine just sleeps X minutes, then asks the terminal what type it is. Go back to sleep, ad nauseum. Has the advantage that the responce comes from the terminal itself, then through the data lines, muxes, data switches, and god knows what else, instead of the cpu just talking to itself. I wrote this when our logout was 20 minutes, about the time it takes to take a leak, get some coffee, and talk to the new blond in accounting. Jim "I deleted that sucker. Honest!" -- Jim Harkins jlh@loral.cts.com Loral Instrumentation, San Diego
karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) (12/02/88)
gwyn@smoke.BRL.MIL (Doug Gwyn ) writes:
and anyway why should a process have to
disable SIGHUP in order to do its natural job?
Perhaps I'm dense today, but I don't understand the question. Any
process doing critical work has to protect itself from a variety of
sources of abuse. And OSes protect themselves with (the non-UNIX
equivalent of) spl7() when entering a critical region. And a lot of
applications perform checkpointing when they finish a large,
logically-complete chunk of some much larger task. And so on...
I guess my question is, Why shouldn't a process be responsible for its
entire state, short of the superuser attack with SIGKILL? I write a
lot of code that has to survive disconnection from the controlling
terminal, at least long enough to clean up and leave the world in a
sane state.
--Karllai@vedge.UUCP (David Lai) (12/02/88)
I wrote a little script that uses output from 'w', and output from 'ps', and if 'w' reports more than 1 hr idle time on a dialin port, then it kill -HUP's all processes on that port as reported from ps. It does have a problem, perhaps someone can elaborate on, it logs the user off, but keeps the carrier on, so the line is useless anyways. Is there some way to force the carrier to be dropped on a KILL -HUP? (sun 3, ALM, port configured for modem, DTR dropping will hang up, but kill -HUP doesn't seem to do it). -- "What is a DJ if he can't scratch?" - Uncle Jamms Army The views expressed are those of the author, and not of Visual Edge, nor Usenet. David Lai (vedge!lai@larry.mcrcim.mcgill.edu || ...watmath!onfcanim!vedge!lai)
evren@wuibc.UUCP (Evren Senol) (12/02/88)
At Washington University in St. Louis, we have a computer room with over 50 terminals for engineering students' use. The room is open 24 hours a day, 7 days a week. There is actually a process running on the machines that can be accessed from those terminals for autologout of idle terminals. I think that for terminals that are accessible to a large number of people, such as the terminals in the above mentioned room, an autologout feature is most appropriate. Among the reasons for this are: 1. Sometimes students leave the terminals idle for a long time, thus make it inaccessible to those curtious students who would not log them out and use the terminal. Autologout would permit them to do so, and place the blame to the system. 2. The processors used by students are usually very loaded. Unused terminals tie up tty ports and increase the response time of a time shared systems used. Thus autologout is a good idea in this case as well. Evren Senol...
jfh@rpp386.Dallas.TX.US (The Beach Bum) (12/02/88)
In article <7043@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: >Or you could use "at now" which will mail any output to you. >Neither is very useful if there is any chance that you will be prompted >for new media. This *IS* comp.unix.WIZARDS. Please RTFM before posting. The manual page for at(1) states "\fBat now\fR will respond with the error message too late." Script is typescript, started Thu Dec 1 20:07:20 1988 Subscript out of range. 1 - rpp386-> at now at: too late 2 - rpp386-> exit 3 - rpp386-> logout Not a terminal: Not a character device John's Words of Wisdumb - Take everything in stride. Trample anyone who gets in your way. Script done Thu Dec 1 20:07:31 1988 -- John F. Haugh II +-Cat of the Week:--------------_ /|- VoiceNet: (214) 250-3311 Data: -6272 |Aren't you absolutely sick and \'o.O' InterNet: jfh@rpp386.Dallas.TX.US |tired of looking at these damn =(___)= UucpNet : <backbone>!killer!rpp386!jfh +things in everybody's .sig?-------U---
charlie@mica.stat.washington.edu (Charlie Geyer) (12/02/88)
In article <KARL.88Dec1155436@triceratops.cis.ohio-state.edu> karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) writes: >gwyn@smoke.BRL.MIL (Doug Gwyn ) writes: > and anyway why should a process have to > disable SIGHUP in order to do its natural job? > >I guess my question is, Why shouldn't a process be responsible for its >entire state, short of the superuser attack with SIGKILL? I write a >lot of code that has to survive disconnection from the controlling >terminal, at least long enough to clean up and leave the world in a >sane state. Just out of curiosity, how do I get my login shell to ignore SIGHUP? If I log in, fire up X windows, run xterm on a remote machine talking to the X server on my machine, the login shells on my machine (two of them, the console hidden by X and my root X window) may be idle for long periods of time. But I'm sitting here typing away at the keyboard and the pseudo-ttys associated with the xterm's on the remote machine have only very short idle times. If you send SIGHUP to either of the login shells on my machine, I lose everything. I'm sitting here looking at a login prompt. UNIX doesn't just talk to dumb terminals anymore. Maybe "Autologout of unused terminals" is a bad idea. If implemented, it should come with an easy way that any user can defeat it, and then what's the point?
hurf@batcomputer.tn.cornell.edu (Hurf Sheldon) (12/02/88)
The user hostile cant some of the comments re: response
to users who left themselves logged in was disturbing. Active
computer fluent users rarely leave themselves logged in unless
there are mitigating circumstances. Many non computer types who
are simply trying to do their work on a computer often leave themselves
logged in. We have taken the tack of only looking for idle
users after hours and if our system user quota is full. Being
irritated at absent minded non computer people and irritating
them in turn as a response is counter productive. If resource
management becomes necessary, even the unfluent (as opposed
to the effluent) become familiar with the constraints of their
work environment (and will probably begin to depend on the computer
to log them out if nothing has been doing on their line).
From a practical standpoint it seems logins idle longer than 1hr
after 7:pm are good bets to cut off. Idle logins greater than
30 minutes in a busy public area, idle network logins from
hosts known to be pc's or unfamiliar hosts and idle dialup lines
are all good candidates for the axe, too.
A program to see who, what tty, how long and what day and time of
day, assign and total priority values and logout any login that
accumulates enough points would be nice. There could be a
weighting factor given to particular lines in /etc/ttys for insecure
or public terminals. I will take a stab at it next week if nobody
has done it already. Suggestions welcome.
hurf
--
Hurf Sheldon Network: hurf@ionvax.tn.cornell.edu
Lab of Plasma Studies Bitnet: hurf@CRNLION
369 Upson Hall, Cornell University, Ithaca, N.Y. 14853 ph:607 255 7267
I sold my Elan, got a job in science; Now, no one takes me seriously.bengsig@orcenl.uucp (Bjorn Engsig) (12/02/88)
(I was the person originally requesting the autologout) In article <17667@adm.BRL.MIL>, gwyn@BRL.MIL (VLD/VMB) writes: > [ ... ] A small reward would be quietly given to > the snitch and administrative action (perhaps a fine) would be > taken against the offender. That might work in your organization, but it would do no good here! > > Then the TMOUT (or TIMEOUT) feature has already been mentioned; it > provides a much better controlled way to terminate forgotten > terminal connections, and has the important feature that IT CAN BE > DISABLED by the user who knows that it would cause him problems. Correct, and wrong: Timeout needs to be implemented in whatever "shell" all users could possibly be using. In our environment this could be a real shell (sh, csh, etc.) or it could be a menuing system, another command interpreter, or something else. And if you want to disable autologout, a signal(SIGHUP,...) or nohup would do perfectly well. -- Bjorn Engsig, ORACLE Europe \ / "Hofstaedter's Law: It always takes ..!uunet!mcvax!orcenl!bengsig X longer than you expect, even if you phone: +31 21 59 56 411 / \ take into account Hofstaedter's Law"
gwyn@smoke.BRL.MIL (Doug Gwyn ) (12/02/88)
In article <KARL.88Dec1155436@triceratops.cis.ohio-state.edu> karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) writes: >gwyn@smoke.BRL.MIL (Doug Gwyn ) writes: > and anyway why should a process have to > disable SIGHUP in order to do its natural job? >Perhaps I'm dense today, but I don't understand the question. Your proposal would force the shell to disable SIGHUP for itself and all its descendants, in order that your ill-advised assault on legitimate processing not be prematurely aborted. In that case, not only is SIGHUP not longer useful for anything, but also the legitimate uses that it had (to clean up when a connection was severed, for example) have been lost.
gwyn@smoke.BRL.MIL (Doug Gwyn ) (12/02/88)
In article <1086@entropy.ms.washington.edu> charlie@mica.stat.washington.edu (Charlie Geyer) writes: >UNIX doesn't just talk to dumb terminals anymore. Maybe "Autologout >of unused terminals" is a bad idea. If implemented, it should come >with an easy way that any user can defeat it, and then what's the >point? Yes, all of that is relevant. The point of a user-defeatable autologout is that sophisticated users can avoid being bothered by this misfeature, while naive users would have this system-administrator-determined policy automatically enforced "for their own protection". Someone else commented about the "user hostile" responses. It is not the user that I'm hostile to; it's the system administrator who thinks he knows how I ought to be using the system and tried to force me to conform to his mistaken usage model. By all means protect naive users if you and they both agree that they need to be protected, but don't try to protect the knowledgeable user against using the resources in perfectly reasonable, although unusual, ways. Learn what UNIX was all about!
gwyn@smoke.BRL.MIL (Doug Gwyn ) (12/02/88)
In article <9041@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >Your proposal would force the shell to disable SIGHUP for itself and >all its descendants, in order that your ill-advised assault on legitimate >processing not be prematurely aborted. Of course this was INTENDED to say "not cause the processing to be prematurely aborted". The sooner the assult is aborted, the better!
jbayer@ispi.UUCP (Jonathan Bayer) (12/03/88)
In article <9012@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn ) writes: > In article <2682@sultra.UUCP> dtynan@sultra.UUCP (Der Tynan) writes: > > Because any automated scheme you come up is likely to ALSO kill off > some perfectly legitimate jobs. > > I have, nearly every day, important connections between a "terminal" > and a host computer that appear to have no activity on them for a > long time, sometimes hours. However, the connections are needed and > cannot be opened only at the time they are active; they must be > arranged in advance then just sit there. An automatic "kill idle > terminal" daemon would wreak havoc with this. Not if you can specify configuration information to the idle-killer via a config. file. We have such a product which will ignore specific users (let them stay on forever), ttys , etc. It is actually fairly easy to write. Jonathan Bayer Intelligent Software Products, Inc.
les@chinet.chi.il.us (Leslie Mikesell) (12/04/88)
In article <8994@rpp386.Dallas.TX.US> jfh@rpp386.Dallas.TX.US (The Beach Bum) writes: >This *IS* comp.unix.WIZARDS. Please RTFM before posting. >The manual page for at(1) states "\fBat now\fR will respond with the >error message too late." Nits.. The machine I am typing on happens to be a unix PC which doesn't have "at" at all. Anyway: at now + 1 min should work if you are unable to think of a more suitable time. Les Mikesell
karl@ddsw1.MCS.COM (Karl Denninger) (12/04/88)
In article <8994@rpp386.Dallas.TX.US> jfh@rpp386.Dallas.TX.US (The Beach Bum) writes: :In article <7043@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: :>Or you could use "at now" which will mail any output to you. :>Neither is very useful if there is any chance that you will be prompted :>for new media. :This *IS* comp.unix.WIZARDS. Please RTFM before posting. :The manual page for at(1) states "\fBat now\fR will respond with the :error message too late." Try "batch" or "at -qb" (same thing as "batch"); all this assumes System VR2 or above. Speaking of RTFM jfh.... :-) -- Karl Denninger (karl@ddsw1.MCS.COM, ddsw1!karl) Data: [+1 312 566-8912], Voice: [+1 312 566-8910] Macro Computer Solutions, Inc. "Quality solutions at a fair price"
guy@auspex.UUCP (Guy Harris) (12/04/88)
>Hmmm, mine just sleeps X minutes, then asks the terminal what type it is. >Go back to sleep, ad nauseum. Has the advantage that the responce comes >from the terminal itself, then through the data lines, muxes, data switches, >and god knows what else, instead of the cpu just talking to itself. Has the disadvantage that it doesn't work worth a damn if: 1) your terminal doesn't have a sequence that provokes it into identifying itself; 2) your program doesn't know the sequence for your terminal, or doesn't know what kind of terminal it is; and isn't very polite if it breaks into the middle of some output to send that sequence and the sequence happens to cause the output to be scrambled.
guy@auspex.UUCP (Guy Harris) (12/04/88)
>>Or you could use "at now" which will mail any output to you. > >This *IS* comp.unix.WIZARDS. Please RTFM before posting. > >The manual page for at(1) states "\fBat now\fR will respond with the >error message too late." So try "batch" (or "at -qb" - "batch" is just a dumb script wrapped around "at -qb") instead, presuming you're on a system with an S5R2-or-later-style "at".
jik@athena.mit.edu (Jonathan I. Kamens) (12/05/88)
In article <1086@entropy.ms.washington.edu>, Charlie Geyer (charlie) writes: >UNIX doesn't just talk to dumb terminals anymore. Maybe "Autologout >of unused terminals" is a bad idea. If implemented, it should come >with an easy way that any user can defeat it, and then what's the >point? Well, here at Project Athena, we've had the autologout code commented out in our /bin/csh (/bin/csh is the default shell for all of our users, and practically no one uses any other) sources for at least a year and a half. When *all* the terminals on a workstation are windows and a user may in many cases spend an hour working in an emacs window without touching a terminal window, autologout is fatal. Of course there was this other teeny weeny bug which caused the X server to crash, thus logging out the user, if the user had a black background and the screensaver kicked in... but we won't talk about that :-) Jonathan Kamens MIT Project Athena
furlani@broadway.UUCP (John Furlani) (12/06/88)
In article <9012@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn ) writes: > In article <2682@sultra.UUCP> dtynan@sultra.UUCP (Der Tynan) writes: > >Anyway, perhaps you'd like to let me know > >why it's such a terrible sin to kill these jobs. > > Because any automated scheme you come up is likely to ALSO kill off > some perfectly legitimate jobs. > There has been quite a bit of chatter over wether to kill or not to kill idle processes. I whipped up this little C Shell script that can be used as an example of how to kill some idle processes and not others. A users original shell is marked with a '-' before it. This can be killed leaving all background processes intact. Unfortunately all forground processes will be killed. This script has a simple way of checking for these. The names of some processes that shouldn't be killed (e.g. vi, kermit) can be put in a file. The basic idea is to get the terminals that have been idle for more than 30 minutes and check to see if they're running anything important. If they are, don't kill them, if they aren't, kill them. This could be run out of cron every half hour or so. It should be noted that this idea won't work for window systems. My original thought was to use it to clear modem tty's since there are generally fewer of them and the demand is higher. I hope this has jogged a couple of minds. I'm not sure how many systems this script will work for, but the principle should stay the same. Please mail me any suggestions or thoughts. ######################################## # CLEARS TTY OF IDLE USERS ######################################## # set dkill = 0 set tty_over = `who -u | awk '$6 ~ /:/ {print $2, $6}' | sed 's/0://' | awk '$2 > 30 {printf $1" "}'` foreach tty ($tty_over) set proc_name = `ps -ft$tty | sed '1d' | awk '{print $8}'` foreach dont (`cat dont`) foreach name ($proc_name) if($dont == $name) then set dkill = 1 endif end end if($dkill == 1) then echo DONT KILL set dkill = 0 else set kill_proc = `ps -ft$tty | sed '1d' | awk '$8 ~ /-csh/ {print $2}'` echo KILL $kill_proc endif end ____________ Disclaimer: "It's Mine! Mine! All Mine!!" John L. Furlani The University of South Carolina, Columbia SC (...!uunet!ncrlnk!ncrcae!broadway!furlani)
guy@auspex.UUCP (Guy Harris) (12/06/88)
>It does have a problem, perhaps someone can elaborate on, it logs the >user off, but keeps the carrier on, so the line is useless anyways. >Is there some way to force the carrier to be dropped on a KILL -HUP? > >(sun 3, ALM, port configured for modem, DTR dropping will hang up, but >kill -HUP doesn't seem to do it). At least under SunOS 4.0 (and quite possibly under earlier releases), the default behavior is supposed to be that carrier is dropped when the last process that has the terminal open closes it. It may be that: 1) the line is configured for this not to happen (see the "hc" option in GETTYTAB(5)); 2) the "hangup on last close" flag isn't getting set for some other reason; 3) the ALM driver doesn't handle this flag correctly; 4) "kill -HUP" isn't killing off *all* the processes on that terminal, so one of them is still holding the line open. Presumably, you've checked this (some process might ignore SIGHUP, or catch it and either not exit at all or take a long time to exit). If you're running 4.0, the "hangup on last close" flag is accessible to "stty"; try dialing in (so you don't screw some unlucky user while testing) and then do stty -a >(the terminal) and see if "hupcl" (the "hangup on last close" flag) is set or not. If it says "-hupcl", it's not set. Try doing stty hupcl >(the terminal) and then provoke your script into blasting you off and see what happens. If you're running a release before 4.0, the flag can be set, but it cannot be cleared nor can its state be found easily. Try running this small program with its output redirected to the terminal in question: #include <sys/ioctl.h> main() { if (ioctl(1, TIOCHPCL, 0) < 0) perror("TIOCHPCL"); } and then run the script (or some version modified to just go ahead and blast just you, but to do so immediately) and see what happens.
dtynan@sultra.UUCP (Der Tynan) (12/06/88)
A couple of people responded to my posting about having the 'idledaemon' shar
file. However, I tried to send to 'dave@clsib21.uucp', but it bounced. All
33K of it! Could you please send me a good path to your doorstep. Anyone
else who wants a copy, please send me mail with a solid (as opposed to rubber)
path. Of course, if you already have access to a c.s archive, then you don't
need this, do you :-)
- Der
--
dtynan@zorba.Tynan.COM (Dermot Tynan @ Tynan Computers)
{apple,mips,pyramid,uunet}!Tynan.COM!dtynan
--- If the Law is for the People, then why do we need Lawyers? ---mac@ardent.UUCP (Mike McNamara) (12/06/88)
In article <213.nlunix6@orcenl.uucp> bengsig@orcenl.uucp (Bjorn Engsig) writes: >What I asked for in the first place was just a program to send SIGHUP to >processes, which seemed to be doing nothing. There will of course always >be cases where this 'seems' is wrong, but a process that wants to live could >easily do signal(SIGHUP,handler) (or nohup). When doing this, you show that >you are aware of the possible 'auto-killing', and you will be sure not to be >killed. This is also a nice thing to do on a modem line. Hmmm. What is the phone number to your system? You actually ignore SIGHUP on dialup lines? I'll just try your phone number every once in a while (ok, I'll get a friend on the continent to try...) until I get in just after you turn your home modem or terminal off without logging out. No need for a virus! (It especially helps if you leave backgrounded su shells... or games with high scores are good too!) Note: a good 15% of the bandwidth on the SYTEX network at school went into programs the students wrote to echo ^@ at their terminals every 30 seconds so the SYTEX wouldn't drop their line. This wasn't due (only) to students wishing to hog terminal lines. The Unix systems hooked up to this terminal server ignored DTR. In fact DTR was wired high on the back of the VAXen. (Or perhaps the DZ/DH or what ever didn't do modem control.) Hence defeating the auto-disconnect `feature' of the terminal network was required to maintain the security of your account. If the SYTEX dropped your line, Unix ignored (never saw) HUP. The next user, *ANYWHERE ON CAMPUS*, who connected to the same machine via the switcher, got your existing login. Pity the poor system manager, connected through the SYTEX, who pauses to answer a users question... *DISCONNECT*. Across campus, the student's buddy, CONNECTS. His terminal prints # Moral dilema. Stupid site configuration. (Of course the Unix admin's inherited the hardware with it's DTR ignorant terminal multiplexors, and the guys in the IBM shop owned the SYTEX...)
ebh@argon.UUCP (Ed Horch) (12/07/88)
In article <1874@loral.UUCP> jlh@loral.UUCP (Physically Pffft) writes: >In article <3603@jpl-devvax.JPL.NASA.GOV> lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) writes: >>Not only that, but idle-killers are so easy to spoof, unless you disable >>people from executing utime() or ioctl(). > >Hmmm, mine just sleeps X minutes, then asks the terminal what type it is. >Go back to sleep, ad nauseum. Has the advantage that the responce comes >from the terminal itself, then through the data lines, muxes, data switches, >and god knows what else, This is a good idea, since some autologout mechanisms reside in the data switch rather than the host. X minutes of no traffic and the fascist switch drops the data call. My solution to this would be to fire up a program that prompts for a password, and doesn't exit until the user's password is correctly typed, or the call is dropped. Every X/2 minutes, invisibly repaint the Password: prompt to keep the autologout fascists happy. That way, nobody can walk up to a terminal and wreak havoc in somebody else's shell, but the call can be dropped by dropping the line. -Ed
dlm@cuuxb.ATT.COM (Dennis L. Mumaugh) (12/08/88)
In article <3603@jpl-devvax.JPL.NASA.GOV> lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) writes: >Not only that, but idle-killers are so easy to spoof, unless you disable >people from executing utime() or ioctl(). > Try the following short script: while : do touch `tty` sleep 600 done & Other more sophisticated scripts can be done. Most shells have a time out but that can be eliminated by people getting into the habit of hitting <RETURN> once in a while. The neatest special program is the 630MTG program dmdlock. If the terminal has no user activity - mouse or keyboard - in a given time period, the terminal locks itself and 15 minutes later the screen blanks. One has to then unlock the terminal. Hence walking away from the 630MTG results in auto-locking the terminal. -- =Dennis L. Mumaugh Lisle, IL ...!{att,lll-crg}!cuuxb!dlm OR cuuxb!dlm@arpa.att.com
karl@dinosaur.cis.ohio-state.edu (Karl Kleinpaste) (12/08/88)
dlm@cuuxb.ATT.COM (Dennis L. Mumaugh) writes:
The neatest special program is the 630MTG program dmdlock. If
the terminal has no user activity - mouse or keyboard - in a
given time period, the terminal locks itself and 15 minutes later
the screen blanks. One has to then unlock the terminal. Hence
walking away from the 630MTG results in auto-locking the
terminal.
...30 seconds too late. After all, if I'm seriously interested in
abusing dlm's terminal, I'm going to wait until, e.g., he goes for his
regular about-10am coffee break outside the machine room. Then I'll
just step into his office before his 630 dmdlock kicks in, and by the
time it *does* kick in, I have committed whatever abuse I had in mind.
Of course, if dlm locks his office with religious fervor any time he
steps outside of it, then I'm out of luck. But then, his dmdlock is
rather pointless, too.
Moral, of course, is never to leave your terminal unattended in the
first place. Unless the `given time period' is measured in small tens
of seconds, it's an inadequate security device.
--Karljbn@glacier.STANFORD.EDU (John B. Nagle) (12/08/88)
The solution used in some high-security environments is to build a
physical fence around the terminal and its user. Opening the gate in
the fence forces an immediate logout.
This is more than most sites would want. However, it might not
be unreasonable in some installations to protect priviledged terminals
in this way.
John Naglerwhite@nusdhub.UUCP (Robert C. White Jr.) (12/09/88)
in article <17885@glacier.STANFORD.EDU>, jbn@glacier.STANFORD.EDU (John B. Nagle) says: > > > The solution used in some high-security environments is to build a > physical fence around the terminal and its user. Opening the gate in > the fence forces an immediate logout. But every time your boss comes to visit you have to explain why you arn't even loggend in ;-) > This is more than most sites would want. However, it might not > be unreasonable in some installations to protect priviledged terminals > in this way. There is a shell-over-login aproach which I have deduced, but not tried. you move "/bin/login" to "/bin/login2" and make the following program into "/bin/login": (general description, not code fragment I leave the actual code as an excersize to the reader) static int loginpid; void killsession() { /* kill loginpid and MAKE SHURE it's DEAD depend on Death-of-parent for exit */ while (0 == 0) { kill(loginpid,9); sleep(3); } } void watcher() { /* get current time in seconds fstat stdin */ /* if stdin_time - current_time > allowable then killsession */ } main(argc,argv) int argc; char *argv[]; { if (fork()==0) { loginpid = getppid(); /* SET SIGNAL TO CALL Killsession on any significant signaling event to prevent user from killing processes and voiding the intent of this file. Death-of-parent should not be trapped to allow abortive exit. */ watcher(); } else { execv("/bin/login",argv); exit(-1); } } WHY THIS WORKS: After the fork the PARENT process is exec(ed) to login which fufills login's requirement that its parent be init. The child process is set to be ended when the parent dies for any reason, so the program needs no exit state. If the child process receives any kind of signal it will kill the login process/first shell/primary environment/whatever which was it's parent. If fstat reveals that the communication port has not been read-from or written-to within an acceptable time (via fstat of stdin, do not use stat on /dev/tty as this is often updated by many people) the login/etc. process is killed; and the child process is signaled to death in the process. Warning: MAKE SHURE YOU HAVE one (or more) terminal logged in as root, and another one on which to preform the test of the installation. If you don't do this you could end up not logged in as anything, and have no working /bin/login to let you in al all. THIS CAN BE A REAL NIGHTMARE! Disclaimer: I didn't write the program, I only came up with the idea. IF it dosn't work, or it damages your system, don't look at me! I DIDN'T WRITE IT and I'm not in the habbit of taking the blame for things I didn't do. Rob.
rang@cpsin3.cps.msu.edu (Anton Rang) (12/09/88)
Lots has been said on this, so just one fairly quick note. It is
possible to compromise (gasp!) between these positions. The
autologout program my undergrad school uses ("Bouncer"), locally
developed, includes the following:
1. It kills idle jobs after half an hour. "Idle" is defined as
processes which aren't using CPU or doing I/O. This is modified by a
set of configuration files and other things....
2. "Disconnected" jobs (terminal jobs not currently connected to a
physical terminal, for those of you who don't know VMS) are not killed
(since they aren't hooked up to a terminal, they aren't using enough
resources to be worth killing).
3. There is a list of users who are never killed (in a file). This
isn't used much, but is available in the rare cases when needed.
4. There is a list of images (filenames) which shouldn't be killed
as long as any job in their "process tree" is running. For instance,
a suspended editing process shouldn't be killed if its parent is doing
work. (Again in a file.)
5. There is a list of terminals that users are never bounced from.
This is mainly for the system console.
6. This is the nice one (that makes reading all this worthwhile
:-). Under VMS, each process has a list of "identifiers" (sort of
like groups under UNIX, but not exactly). There is a "NOBOUNCE"
identifier which tells Bouncer not to kill the process, even if it
would otherwise be eligible for killing.
Suitably privileged users can turn this on and off (not superusers,
just ordinary users who are allowed to do it--could be everyone). So
if you're in your office and going out to lunch, locking the door
behind you, you could do a SET RIGHTS/ADD=NOBOUNCE (or something like
that) and know your process would still be there. You could turn it
off later, if you wanted.
So it *is* possible to compromise, with a little extra effort....
+---------------------------+------------------------+----------------------+
| Anton Rang (grad student) | "VMS Forever!" | "Do worry...be SAD!" |
| Michigan State University | rang@cpswh.cps.msu.edu | |
+---------------------------+------------------------+----------------------+ugbernie@sunybcs.uucp (Bernard Bediako) (12/10/88)
What if once the TIMEOUT or autologout value is reached, a call is
made to make the user retype in his passwd instead of logging him/her out.
Once we gets to this point it could either wait forever or until another
predetermined amount of time. If the passwd is wrong, log the user out.
This might at least stop other people from happening along & doing rm *.* :-)
bernie.
------------------------------------------------------------------------
Bernard Bediako SUNY/Buffalo Computer Science
UUCP: ..!{ames,boulder,decvax,rutgers}!sunybcs!ugbernie
Internet: ugbernie@cs.Buffalo.EDU BITNET: ugbernie@sunybcs.BITNET