hang on exit bug under Linux

[Nicolas Williams]

On Fri, Dec 14, 2001 at 06:10:59PM +0100, Peter Stuge wrote:
> On Fri, Dec 14, 2001 at 01:58:42AM +0100, Peter Stuge wrote:
> > 
> > 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..
> 
> Ok.  Here we go.  It's not very complicated but it took me some time to get
> familiar with all the code, which is very easy to read, kudos to all!
> And after finishing it, I fell alseep.  Ohwell.
> 
> For this to work as desired the sshd must send the SSH_MSG_CHANNEL_CLOSE
> message fast enough for the client to buffer it together with the
> CHANNEL_REQ "exit-status", so that CHAN_CLOSE_RCVD is set in the channel
> flags when client_process_buffered_input_packets() returns.  If this isn't
> acceptable/practical the only alternative I can see is to set a time limit.
> 
> The case I'm trying to handle here is "exit-status received for this
> channel, but no SSH_MSG_CHANNEL_CLOSE" - when is that a fact?  Sure, if some
> other packet than _CHANNEL_EOF or _CHANNEL_CLOSE is received, I'll know.
> And I implemented that first, using a dispatch_preprocess function that
> would be run before the message handler. But that doesn't cut it when there
> simply aren't any packets arriving..

Hmmm, I would say, if you're backgrounding, you don't care, because if
the _CHANNEL_CLOSE is going to arrive you'll exit then anyways...

If you're going to exit and risk losing data, then you also don't care
when, if ever, the _CHANNEL_CLOSE is to arrive. I would agree that a
one-second timer would be nice, but, hey, folk are asking for the right
to risk losing data - let them have it.

> On top of this, much to my disappointment, a backgrounded ssh didn't get
> killed when I closed my xterm.  But if it lingers it gets killed.  This is
> because bash sends SIGHUP to all jobs when it is exiting.  But since the ssh
> fork()s, it's no longer considered to be a job.  Hmm.  I tried putting a
> call to setpgrp() and then setsid() in the fork()ed off child, but that
> didn't make any difference, obviously I guess.  Is what I want even
> possible?

This is because each "job" gets its own process group and the tty send
SIGHUP only to the lead job.

> Tell me if I've done something wrong in the patch.  It makes ssh in any case
> tell the user about what is happening and why, wheter it lingers, goes to
> background or terminates.

I don't see a check for whether there are other live sessions. That should
be needed because SSHv2 supports multiple sessions per-connection. I
think there was a patch floating around to implement a ~ escape for
starting new sessions... For now this is no big deal, but it should be
easy to add a session_still_live() function to check.

> 
> //Peter
> 
> -- 
> irc: CareBear\
> irl: Peter Stuge


Cheers,

Nico
--
-DISCLAIMER: an automatically appended disclaimer may follow. By posting-
-to a public e-mail mailing list I hereby grant permission to distribute-
-and copy this message.-

Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.