mmorse@note.nsf.gov (Michael Morse) (05/04/88)
A few months ago I posted a notice asking for help with a problem
where one user would enter into the session of another who had
disconnected abnormally. Since then I've learned that the computer
press, if not the workers, have a name for this problem: tailgating.
First, I'd like to thank everybody who responded. Most suspected
the MICOM port selector was either malfunctioning or mis-configured.
While there seems to be some hostility toward MICOM out in the net, in
this case the MICOM was innocent.
For those coming in late, here's the scenario:
1. We're running a VAX 785 (ULTRIX) with 48 async ports connected to
a MICOM port selector. On the other side of the MICOM are over a
1,000 terminals contending for those ports.
2. Sometimes a user gets disconnected without issuing the "logout"
command. I call these "MICOM initiated disconnects" since it is
the MICOM that starts the disconnect process by dropping carrier
detect signal to the VAX. Usually this is no problem. The c-
shell notices the hangup signal and dies. However, sometimes this
doesn't happen, and the session continues.
3. The next user to connect to the VAX ends up in the already running
session of another person.
We've learned quite a bit about the cause of the problem. What
seems to happen is this:
1. A program running uses the signal function to ignore the hangup
signal.
2. The hangup occurs, but is ignored by the program.
3. The program attempts to write to the terminal.
The last part is the critical part. If the program simply ends
without attempting output, the session is properly terminated.
Things seem to behave a little differently while the c-shell is
executing the commands in .login, but I'm less clear on exactly the
symptoms. For example, you can solve the problem for normal programs
by simply removing the signal call (of course you might break someth-
ing else!). However, in .login, you may still see the problem in some
cases which I haven't completely isolated.
Incidently, we've reproduced this on a BSD 4.3 system, so it's not
specific to ULTRIX.
Would anybody care to comment on this? Is this a bug or a
feature, or just something that all programmers are supposed to know?
The explanation that I've been given is that the C-shell does not
exit (and thus end the session) because it's waiting for the child
process to die and the child is waiting for its terminal I/O to
complete. When the MICOM eventually brings up carrier detect (someone
else wants a port), the I/O completes, and everything seems cool so
the C-shell just goes on its merry way as if nothing had happened.
Comments anybody?
--Mike Morse
National Science Foundation
Internet: mmorse@note.nsf.gov
BITNET: mmorse@NSF
Phone: (202) 357-7659