abm@cbnewsm.att.com (andrew.b.myers) (12/09/90)
What's the best sure-fire way to kill a login shell instantaneously
if a user disconnects "ungracefully"? I'm sure anyone who knows
anything about system administration can help me. I just don't
happen to know anything about system administration.
Here's the setup: I've got a 3B2-300 running UNIX 3.0. I've created
a restricted login (/bin/rsh) called "go" with no password required.
The login prompt tells the user to type 'go' which sets everything in
motion.
The .profile executes a shell script that I have bullet-proofed
every way but Sunday, so "go" can't escape and mess around in UNIX.
This is going to be a simple bulletin board open to anyone who wants
to scan files in a directory I've set up. As I said, the last line
in go's .profile is
exec /usr/my_bin/my_script
where my_bin is a directory I created just for this script and related
utilities and my_script is the shell script user interface I wrote for
scanning files a la CompuServe or similar bulletin boards. I under-
stand that exec causes the original login shell to die and a new shell
is spawned as the my_script program kicks in.
Right now I'm testing it with a single 1200 baud dialup port coming in
through a Hayes modem. Everything works fine except when 'go' simply
disconnects without actually quitting, something I suspect many users
will do. The new shell created by exec just keeps going. When the next
user dials up to the same port, he/she gets this munged shell instead of
a fresh login prompt. Because some child processes were killed off when
the previous user suddenly disconnected, the whole thing is a mess.
So now I need an instantaneous sledge hammer to kill the abandoned
shell when a user suddenly drops off.
This behavior is completely repeatable. If I look for living processes
after an "ungraceful" disconnect I always find that same tty running
the leftover shell. A who -uT not only indicates Mr. "go" still logged
in, but active! Therefore my idle user script (which works fine
otherwise) won't kill the abandoned login.
Could this abandoned-but-active shell be related to the fact that the
port is connected to a modem? Is there anything I can do with the Hayes
to prevent this behavior? Is there some kind of UNIX deamon anyone has
to keep watch over this and kill an abandoned shell? Is the problem
related to /bin/rsh? Is there a better way to set up a simple "public"
bulletin board? Any advice welcome...
Thanks in advance and don't bother posting. Please email to att!brpr04!abm
--andy myers--
--
========================================================================
Andrew Myers AT&T, Basking Ridge, NJ ...attmail!abmyers
Public Relations 201-221-2737 ...att!brpr04!abm
========================================================================abm@cbnewsm.att.com (andrew.b.myers) (12/11/90)
In article <1990Dec9.020043.273@cbnewsm.att.com>, abm@cbnewsm.att.com (andrew.b.myers) writes: > > What's the best sure-fire way to kill a login shell instantaneously > if a user disconnects "ungracefully"? I'm sure anyone who knows > anything about system administration can help me. I just don't > happen to know anything about system administration. > > [description of the problem deleted...] > -- > ======================================================================== > Andrew Myers AT&T, Basking Ridge, NJ ...attmail!abmyers > Public Relations 201-221-2737 ...att!brpr04!abm > ======================================================================== I am following up to my original ariticle to let you all know a fix has been found. The operative advice came from Tom Gillespie (tag@mtunf.att.com) who suggested I try setting a trap to cause the shell to commit suicide upon hangup. Simple fix, and it works fine. For those who asked me to let them know if I found a fix, just put this in the user's .profile or (as I did) within the shell script itself: trap "kill -9 0" 1 This issues a large sledged hammer kill on the parent and all child processes upon detection of SIGHUP (Signal 1). I erred in saying earlier that Mr. "go" was still logged in. What I saw was an active abandoned rsh when I checked with ps -ef. A who -a indicated the user was not logged in. Thus the problem wasn't with the modem at all. In fact, I was able to duplicate the abandoned shell behavior using another hardwired port. The modem works fine. For those who asked, the switch 6 was set UP and properly dropped DSR upon hangup. Thanks very much to all those who responded! This damned net is fantastic. --andy myers-- -- ======================================================================== Andrew Myers AT&T, Basking Ridge, NJ ...attmail!abmyers Public Relations 201-221-2737 ...att!brpr04!abm ========================================================================