stopped jobs don't always disappear (after logout)

[Dave Lennert]

> Most UNIX kernels that support job control have a provision
> for cleaning up stopped jobs when the user insists on logging
> out without taking care of them.  4.2 does this within exit()
> by checking if any of the exit'er's children have been suspended.
> If so, it sends each such child a SIGHUP followed by a SIGCONT.
> 
> A problem occurs in cases when programs fork/exec with the
> parent ignoring SIGHUP during its wait().  If this job is suspended,
> peculiar things happen when the user logs out.  When the login
> shell exits, the kernel notices the stopped child and sends it a
> SIGHUP which is ignored.  The subsequent SIGCONT simply changes the
> process state from stopped to wait/blocked.  The child's child is never
> sent any signal.  This results in both processes hanging around with
> the parent blocked and waiting for a child which is suspended.

You're right.  Exit() should probably send SIGHUP & SIGCONT to the
entire process group rather than just the immediate stopped children.
However, if some children (other processes in the process group) were
not currently stopped, this would kill them unexpectedly.  (Remember
that in 4.2 based systems, SIGHUP is usually sent to only *some* 
processes when a user logsoff.)

The bottom line is:  If a process ignores SIGHUP, it better know what 
it's doing.


    Dave Lennert                ucbvax!hpda!davel               [UUCP]
    Hewlett-Packard - 47UX      ihnp4!hplabs!hpda!davel         [UUCP]
    19447 Pruneridge Ave.       
    Cupertino, CA  95014        (408) 447-6325                  [AT&T]