so-called-hang-on-exit

[Nicolas.Williams at ubsw.com]

Jani,

Sshd normally doesn't use timeouts in the select() loop. That you're
putting a timeout into the select() call "so that the select() call
could not hang forever" indicates you fail to understand what's going
on and are actually implementing a timeout heuristic. That may be a
fine thing to do, but that is what you're doing.

Specifically, in a plain one-channel pty ssh connection to an sshd
on Solaris/Linux, after the session leader exits, if it leaves
background process groups still running, but not interacting with
the pty, then the sshd will sit there in select() waiting for:

 - client requests (as in new channel requests, channel close
   messages, or channel data, say)
 - those background process groups to write something to the pty

The user considers the session to be finished and does *nothing* or
does ~.. If he does nothing then neither does the sshd do anything.

That's what you interpret as "hanging". You want a heuristic which
"flushes" the pty and closes it as if it had produced EOF as it would
on OpenBSD. Perhaps one way to do that would be to read() in a loop
from the master pty until it returns EWOULDBLOCK, then close it and
get the process started by which the channel is then closed. Or you
can use a timeout, that is, keep select()ing on the pty master fildes
for some time then close it. The fact that you're putting a timeout
into the select() indicates that you're doing the latter.

Once the pty master fildes is closed the select loop will only select
on the SSH socket. By this time the client will know that the channel
is closed, and it (the client) will then proceed to tear down the SSH
connection (which is what you want and which will get sshd out of its
select loop and thus get sshd to exit) because that is what ssh clients
typically do when the last open channel is closed (that is what the
OpenSSH client does, though clients are not obligated to do this - they
can just reuse the SSH[v2] connection and open new channels).

Cheers,

Nico
-- 

> -----Original Message-----
> From: Jani Jaakkola [mailto:jjaakkol at cs.Helsinki.FI]
> Sent: Wednesday, August 07, 2002 3:53 PM
> To: Williams, Nicolas
> Cc: fcusack at fcusack.com; openssh-unix-dev at mindrot.org
> Subject: RE: so-called-hang-on-exit
> 
> 
> On Tue, 6 Aug 2002 Nicolas.Williams at ubsw.com wrote:
> 
> > 
> > Why are putting a timeout into the sshd's select() when flushing
> > the PTY?
> > 
> > I'll admit I've neither tried the patch nor really read it. But if
> > you'll rely on timeouts on one side, why not on the other.
> 
> We did not rely on timeouts. The timeouts we're only made so that the 
> select() call could not hang forever.
> 
> I really did want 0 second timeouts, but the way timeout handling was 
> implemented in serverloop.c prevented that (with a minimal 
> patch at least. 
> Personally I would have liked to clean up the timeout 
> handling; Eventually 
> I will have to, since I will port my older IdleTimeout to 
> newer openssh).
> 
> - Jani
> 
> 
> 

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.