un-dedicating a line to a dialer

[Guy Harris]

>  > A sensible system will send a HUP signal to the process group when its
>  > leader dies, and unless the long-runner has been 'nohup'ed (and its
>  > references to the terminal closed), it will die.

> Quite true, however, many of your average "long running" processes
> ignore HUP signals, so your "sensible system" doesn't do a lot of good.

> A better strategy would be to force the terminal closed when
> a user logs out (not just when pgrp leader dies, as that overly
> restricts the use of pgrps).

I assume the "sensible system" mentioned here is USG UNIX, which does, indeed,
zap a pgrp with SIGHUP when the leader dies.  4.xBSD have the "vhangup" call
which is executed by "init" when the leader dies, which has a similar effect -
the 4.1c code (but not the 4.2 code) had comments mentioning that it should
*really* be done by the kernel (i.e., like having the USG code zap all file
descriptors referring to the tty in addition to sending the SIGHUP).

The trick is defining "the user logging out"; the definition used by USG
UNIX is "pgrp leader dying", and the definition in effect implemented by
4.xBSD is also "pgrp leader dying" (because "init" remembers the pgrp leader PID
and, when it dies, respawns "getty"); however, the 4.x implementation of
pgrps is not the same as the USG one.  4.x uses pgrps for job control, USG
(prior to S5R2, anyway) doesn't have job control so that problem doesn't
crop up.  If a system is to have the USG pgrps (along with the SIGHUP) *and*
BSD job control, there would probably need to be *two* kinds of pgrps; one
(call them "process groups") the same as vanilla USG pgrps, and one (call
them "job groups"?) the same as 4.x pgrps.  SIGINT, SIGQUIT, SIGTSTP, etc.
are sent to the job group currently associated with the terminal, while
SIGHUP is sent to the entire process group, unless it's decided that SIGHUP
shouldn't really go to background jobs even if the carrier really drops.

	Guy Harris
	{seismo,ihnp4,allegra}!rlgvax!guy