hang on exit bug under Linux

[Peter Stuge]

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


> > 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?


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

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

What sort of channel did this patch let you create in the new session?  I
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..  :)

Thanks for the input!


//Peter

-- 
irc: CareBear\
irl: Peter Stuge