so-called-hang-on-exit

[Jani Jaakkola]

On Mon, 5 Aug 2002, Frank Cusack wrote:

> > Anyway, I realized that it is probably useless to go through the select 
> > loop after the child is exited to just be able to empty the pty buffer. I 
> > checked, and Linux pty buffer size is just 2048 bytes, which is much less 
> > than 16*1024 buffer in channel_handle_rfd. And since the master processes 
> > have exited, the unread data is guaranteed to have fit into that 2048 byte 
> > buffer.
> 
> Yeah, but you don't know how much of that buffer is available,

Well, of the 16384 byte buffer in channel_handle_rfd always 16384 bytes is 
available. It is just a temporary stack buffer used in channel_handle_rfd. 
Check yourself.

I am sure that the output from the exited children must have fit into the 
pty buffer. If it doesn't, the children could not possibly have exited.

There is also the global server output buffer, but it is already protected 
from filling by the select loop and should be guaranteed to have the 
requires 16384 bytes space. channel_handle_rfd already assumes so. (well, 
I guess that under extreme conditions with hundreds of channels I could 
actually fill the global output buffer and crash sshd; but it is a 
completely different bug and is not relevant to the hang-on-exit thing) 

> and the bug isn't present only on Linux, I thought. 

I guess the pty buffer size varies between diffirent unices. However, I 
would be surprised if it was larger than 16K in any Unix-like OS.

But anyway, if there actually are unices which large pty buffers it should 
not matter. We perfectly good patches for them too.

> I actually tried just emptying the buffer and then doing a 
> chan_read_failed() but this lost data for me. At least I think I tried 
> that. :-)

I did ran quite a lot of tests on my patch. Worked fine for me. 

Can you provide a scenario where my patch should fail?
Where fail means that ssh hangs on pty background processes or loses data 
from foreground processes.

- Jani