hang on exit bug under Linux

[Michael]

> On Fri, Dec 14, 2001 at 01:58:42AM +0100, Peter Stuge wrote:
> > On Thu, Dec 13, 2001 at 05:35:49PM +0100, Wichert Akkerman wrote:
> > > Previously John Hardin wrote:
> > > > ...so you're saying having a "hung" ssh session is okay if it's
> > > > backgrounded?
> > > 
> > > It is if the backgrounded program has not disconnected itself from
> > > the pty.
> > 
> > My point exactly.  And nothing has hung.  The client is lingering, waiting
> > for all remote tasks to complete.  This is the same behaviour you get if you
> > set SO_LINGER on a socket.  Check out socket(7)..  If/when the program in
> > the background (on remotehost) exits, the ssh client and the sshd on the
> > server will also exit.  And if the xterm (or virtual console) gets closed,
> > the ssh client will be killed off, as the sshd on remotehost.  If the
> > backgrounded program on remotehost catches HUP it will stay alive, but any
> > data output from it will be lost.  That's however hard to change from within
> > ssh.
> > 
> > Now off to code up this patch.  Or at least I'll try, had a look at some of
> > the code yesterday too but didn't get anywhere..
> 
> Cool.
> 
> You need options processing code (readconf.c) and session-exit
> processing code. When the client gets a session-exit message, and
> that was the last session still "alive", then do as the user wanted.
> The things to do could be many, as I've suggested before and as I'll
> repeat:
> 
>  - do nothing ("hang" until the session's channels are closed)
>  - background the client (what you suggest)
>  - force the channels closed and exit (what many users want)
>  - pass a SIGHUP to the session in question (reading the drafts this
>  can
>    be done because the session exit message is really associated
>    with the session's channel, therefore, though the session has
>    exited it continues to exist until the channels are closed. The
>    server should kill the process group of the session leader whose
>    exiting elicited the session-exit message).
> 
> You needn't implement all of those options. The first two will do
> for you, apparently, so implement that. The others can be added
> later.
> 

The behavior may be different for V1 vs V2

The old V1 behavior simply exits unconditionally -- whereas V2 waits 
and presumably would be altered by the proposed modification
or....
are V1 and V2 to operate in the same manner???

Michael at bizsystems.com