hang on exit bug under Linux

[Nicolas Williams]

On Tue, Dec 18, 2001 at 12:21:43AM +0100, Peter Stuge wrote:
> On Mon, Dec 17, 2001 at 10:04:46AM -0500, Nicolas Williams wrote:
> > > 
> > > 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.
> 
> If the calls to error() are kept in, it would mean that the message always
> got printed whenever the exit-status request was recevied and also cause the
> _CHANNEL_CLOSE and any other packets sent by the server to never get
> handled..  I wanted to accurately determine the state when exit-message was
> received but not _CHANNEL_CLOSE..  And depending on different server
> implementations, I guess, my assumptions will work..

I still don't understand why you'd care.

Once you've decided that you're going to exit when you get the
session-exit, why wait [more than a short, short period of time]? And
why worry about not handling an SSH_MSG_CHANNEL_CLOSE that might never
come? I mean, if you're exiting because you don't know when the close
message will come, then yeah, you're not going to handle it. That's the
point.

And if you've decided to wait, whether in the foreground or in the
background, then you're waiting anyways and will exit when you get the
channel close message.

I have to look at the patch again to see what these calls to error()
are. But, in any case, ssh should only exit when there's no channels and
sessions still open/alive or when the user forces the client to exit or
when the user has asked that the client exit when the sessions all exit
or when there's an error. Right?

> > > 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.
> 
> The lead job is bash.  And bash forwards the HUP to all it's "jobs"..  But
> since the ssh process that is a child of bash has exited (leaving a new
> process that it fork()ed off) bash never sends the backgrounded ssh process
> a HUP, since it's not a child of bash.  So my question is sort of bash
> related, but I was hoping it was generic to all shells or maybe even
> processes.  I guess I could try to find an answer somewhere in POSIX?

Right. Hmmm, time to crack open the Stevens books...

> > 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.
> 
> Yeah, I realized this when I read up on the protocol.  But since it wasn't
> currently used anywhere in OpenSSH I figured I didn't have to care about it. 
> And because of that I didn't see any obivous way to handle it..

Handle that now and this patch will never get in the way of another...  :)

> What sort of channel did this patch let you create in the new session?  I

I think it was for starting a new session after the current one exited.
Or I could be smoking something...

> can see before me a patch turning OpenSSH into a secure "screen"-program,
> which would be sort of cool, but a bit out of scope, none the less..  :)

It would be cool. I imagine turning ssh into a session agent and agent
client, with a master session agent control Unix socket, and a Unix
socket for each session.

But that's for some other time.

> Thanks for the input!

NP.

> 
> //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.