[294] in Zephyr Mailing List
Re: undead zwgcs
daemon@ATHENA.MIT.EDU (Greg Hudson)
Mon Sep 14 22:36:58 1998
To: Derrick J Brashear <shadow+@andrew.cmu.edu>
Cc: zephyr@MIT.EDU
In-Reply-To: Your message of "Mon, 14 Sep 1998 22:03:15 EDT."
<Added.gpzQgQy00Udi05YE40@andrew.cmu.edu>
Date: Mon, 14 Sep 1998 22:32:19 EDT
From: Greg Hudson <ghudson@MIT.EDU>
Assuming zwgc successfully joins the process group of its session
leader, it will get a HUP on logout if:
* The session leader is running under telnetd (at least the
implementations I've looked at) or xterm, or
* The session leader process group is the foreground process
group at logout time
It may be that neither of these things is true in the cases you're
observing.
zwgc will join the process group of its session leader in all cases on
systems which have getsid() if you have the most recent version of
zwgc's detach(). On systems without getsid(), zwgc uses the process
group of the parent, which is right if zwgc is run directly from the
command line but not necessarily otherwise.
If you have old detach() code (any external zephyr release qualifies
as "old"), then on most systems zwgc will set its process group to the
foreground process group of the terminal at detach() time. If zwgc is
run in the foreground (the usual usage), this is usually a no-op, and
zwgc will not generally get a HUP at logout time. If zwgc is
explicitly backgrounded, then zwgc should actually get the session
leader's process group and get a HUP in the cases mentioned at the top
of the message.
None of this is very robust. What zwgc wants to do isn't really
anticipated by the POSIX (or old Unix) session model, so it can't be
done reliably by expecting to get a SIGHUP. I don't really know of
any better way either.
