so-called-hang-on-exit

[Frank Cusack]

On Tue, Aug 06, 2002 at 10:12:04AM -0400, Nicolas.Williams at ubsw.com wrote:
> 
> Why are putting a timeout into the sshd's select() when flushing
> the PTY?

I'm not.  If you mean forcing the time value to 100ms (instead of NULL)
that's just some arbitrary number sshd already uses.  That's strictly
to prevent a NULL tvp which would ... hang.  unless you have
clientkeepalive's configured.

For the purpose of hang-on-exit, the time value could be '0'.  I don't
see a problem just leaving it at 100 though.

> 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. There's
> the heuristic. I mean, if you want it to be totally correct then
> sshd just has to wait for the pty to close - any other approach
> has to be a heuristic and will allow for data lossage.

Well, right.  Linux/Solaris/others don't close the pty when the session
leader exits (I guess that's the problem).  That's why the option was
called 'AllowDataLossOnPty' by Markus.  *IT ALLOWS DATA LOSS*.  You
still have an open fd you can read from, yet you're going to force it
closed.  If you want to be totally correct, you trust that the OS does
the correct thing and you exit only when there is no more data to read.

hmmm...  what does 'ssh -t 0 "yes & exit"' do on BSD?

> But then, you all seem to be happy with data lossage, whereas I'm
> not happy to be forced to suffer it. So why not a client side
> heuristic, like this:
> 
> if (session-exit && open_channels == 1) {
>     set_timeout(1); /* 1 second - or as configured */
> }
> ...
> 
> and in the event loop add a check for (open_sessions == 0 &&
> open_channels == 1 && open_channel_has_pty()) and then close the
> channel and do the right thing (exit).

Sure, sounds roughly equivalent to me.  But I'm just going with the
flow here.  It does seem better to control this from the server-side.
It may be that your client hangs, but it's really that you are consuming
a resource on the server side.  I like the one guy's argument that
BOTH client and server should have a fix for this.

/fc