so-called-hang-on-exit

[Frank Cusack]

On Tue, Aug 06, 2002 at 09:34:37PM -0500, Ben Lindstrom wrote:
> *WHY* does it happen on some platforms and not others?  You run OpenSSH on
> OpenBSD?  No hang.
> 
> No one has yet to even explain to us why.  If one person could explain why
> without handwaving it would solve the problem because it more than likely
> is a mistake on TTY handling.

McKusick et al say (Design & Implementation of BSD, p. 344):

    If the session leader exits, the controlling terminal is revoked,
    and that invalidates any open file descriptors in the system for
    the terminal.  This revocation ensures that processes holding file
    descriptors for a terminal cannot still access the terminal after
    the terminal is acquired by another user.  The revocation operates
    at the vnode layer.  It is possible for a process to have a read or
    write sleeping for some reason--for example, it was in a background
    process group.  Since such a process would have already resolved the
    file descriptor through the vnode layer, a single read or write by
    the sleeping process could complete after the /revoke/ system call.
    To avoid this security problem, the system checks a tty generation
    number when a process wakes up from sleeping on a terminal, and,
    if the number has changed, restarts the read or write system call.

The bit about having a read or write sleeping b/c of being in a background
process group doesn't seem to apply (if so, shouldn't there be no output?
And the bg process group would get SIGTTOU/SIGTTIN?).

But the bit about invalidating /any/ open file descriptors in the system
for the terminal might hint at where the problem is?

Goodheart & Cox say (The Magic Garden, p. 267):

    if( this process is a session leader ) {
      send SIGHUP to all processes in the group
      and deallocate vnode for controlling terminal
    }

Revoking the controlling terminal doesn't seem to be enough to close
the pty, since [from McKusick] the read or write syscall will restart, but
sending SIGHUP to all processes in "the group" sounds like a killer. :-)
They don't make it clear whether that's all processes in the process
group that the session leader belongs to, or if that's all processes in
the session.  (I don't see any references to the terminology "session
group" in either of the above books and Stevens also stays away from
the term "session group".)  I would bet it's supposed to be all processes
in the session leader's process group but instead BSD sends it to all
processes in the session.  Well, "supposed to be" is a tough statement.

Now, someone who knows more about how this all works can hopefully
piece it together.

/fc