The complete answer (was Re: so-called-hang-on-exit)

[Frank Cusack]

On Thu, Aug 08, 2002 at 12:27:37AM -0400, Nicolas Williams wrote:
>  - Whereas SVR4 doesn't do any of this and relies on the session leader
>    to do its part and HUP/CONT its process groups. This part is not too
>    clear because Uresh Vahalia mentions this very much in passing on
>    page 108 of "Unix Internals."
> 
>    It is unclear whether closing a pty master causes the pty slave
>    driver to take any action, whether sending singals to any processes
>    or revoking any open file descriptors, when the session process is
>    alive or dead at the time that the master is closed. This can be
>    determined experimentally. Ideally closing the pty master after the
>    pty slave's session leader has exited will cause the pty slave driver
>    to revoke open fildes referring to it *and* to send HUP/CONT to
>    remaining process groups with that pty slave association.
> 
>    My tests indicate that closing the master pty, on Solaris, does not
>    cause the slave pty open fildeses to be revoked and not signal is

But it must, otherwise changes in ownership would give access that
shouldn't be there to the bg process group, No?

>    sent, so orphaned background process groups continue to run and
>    clutter up the process table *and*, apparently they continue to
>    consume a pty which cannot be reused until said processes exit or
>    dissasociate from their pty.
> 
>    What about Linux?

Interesting.  If you look at linux/drivers/char/tty_io.c:disassociate_ctty()
 you can see that SIGHUP and SIGCONT are sent.  disassociate_ctty() is called
from linux/kernel/exit.c if the exiting process is the session leader.
Yet Linux has the problem.

> So, Markus, Ben, et. al., I recommend that you close all bugs related
> to this hang-on-exit issue and document the problem as being buggy or
> insufficiently featured shells on Linux/Solaris. Including a patch to
> close the pty master when the session leader exits, on some platforms,
> may be probably a good idea, but it's not absolutely necessary - what
> is absolutely necessary is that the shells on Linux/Solaris know to
> send HUP/CONT to their process groups before exiting.

Ack!  I would say it is needed.  There are *plenty* of other implemented
workarounds for wierd behavior on xyz given platform.  It's too painful
to have to set your shell vars correctly, etc.  What if you use a shell
that doesn't support that kind of thing?  etc.

The patch does no harm.  There's no reason not to include it.

> Jani, Frank, et. al., make sure that your shell is configured correctly
> and/or that you use a shell that correctly implements the SVR4 behaviour

I've known about huponexit forever.  (RedHat documents this as a workaround.)
This is not an acceptable workaround for me.  Now, this isn't really a
problem b/c I have to maintain a local version of openssh anyway, but
I always prefer to have minimal changes, and other folks want/need this
also!

Thanks for investing time in this, Nico.

/fc