so-called-hang-on-exit

[Jani Jaakkola]

On Wed, 7 Aug 2002 Nicolas.Williams at ubsw.com wrote:

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

I did not implement any such thing. Read the patch.

My second patch has no timeouts at all, but it provides almost exactly the 
same behaviour as the first.

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

That was exactly what I did.

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

You did not read the patch. I was doing the former.

As I already said, the fact that the in the first patch was something else 
that 0ms was because I had to work around some historical code in the 
openssh select loop, which was not written by me. I would be happy to fix 
it though, and probably will provide a patch for it (IdleTimeout will need 
it).

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

I agree with all this.

- Jani