[913] in Zephyr_Bugs
Re: possibly more useful patch for zwgc to get HUP on logout
daemon@ATHENA.MIT.EDU (Greg Hudson)
Sun Mar 1 21:44:30 1998
Date: Sun, 1 Mar 1998 21:44:28 -0500 (EST)
From: Greg Hudson <ghudson@MIT.EDU>
To: Greg Hudson <ghudson@MIT.EDU>
Cc: Derrick J Brashear <shadow@DEMENTIA.ORG>, zephyr-bugs@MIT.EDU
In-Reply-To: "[912] in Zephyr_Bugs"
> I'm going to do some empirical testing to see if the situation is
> less bleak than it looks from the POSIX spec and from kernel source
> code.
I did some testing, and the outlook is bleak for robust operation
using the current strategy:
* If you are in the foreground process group, you will get a
HUP, I think from the kernel. So if zwgc is in the process
group of the shell, you will get a HUP if the user logs out
normally but not if their modem connection dies while
they're running a command.
* telnetd and xterm will send a HUP to the process group of
their child process. So again, if zwgc is in the process
group of the shell, it will get a HUP, but only under
telnetd or xterm. If the login was through rlogind or sshd
or getty, no HUP.
So it's understandable why Marc thought it was sufficient to put zwgc
in the process group of the shell; you do get a HUP in a lot of cases,
but not all of them.
So I'm thinking about alternative strategies. You could try to do
something to /dev/tty (select for exceptional conditions?) to get
notified when the session leader dies, but I don't think that will pan
out. Another (rather unpleasant) option is to periodically check
whether zwgc's original parent pid is still around.
