ssh localhost yes | true

[Kyle McKay]

Thanks for your response.

On Apr 20, 2009, at 23:10, Damien Miller wrote:
> On Mon, 20 Apr 2009, Kyle McKay wrote:
>
>> Referring to "CLOSED FIXED" Bug 85:
>>
>>   https://bugzilla.mindrot.org/show_bug.cgi?id=85
>
> ...
>
>> HOWEVER, the "ssh -2 localhost yes | true" command just
>> hangs indefinitely on Mac OS X 10.5.6 where the output of
>> ssh -V is:
>>
>>   OpenSSH_5.1p1, OpenSSL 0.9.7l 28 Sep 2006
>>
>> It turns out that it's the version of sshd that seems to matter
>> as the older ssh OpenSSL 0.9.7l client talking to a newer sshd
>> daemon doesn't hang (and the logs at the end of this message
>> seem to bear that out).
>
> This doesn't look like bug#85 based on what you sent below. It looks
> more like a whatever that you were running failing to notice its  
> stdout
> closing.

Actually after looking at this some more, I think Apple's sshd is just
missing the Bug 85 patch and I think the debug messages back this up.

>>   ...
>>   debug2: channel 0: write failed
>>   debug2: channel 0: close_write
>>   debug2: channel 0: send eow
>>   debug2: channel 0: output open -> closed
>>   connection hangs at this point
>
> The client is doing the right thing.
>
>> and sshd log looks like this:
>>
>>   ...
>>   debug1: server_input_channel_req: channel 0 request eow at openssh.com
>> reply 0
>>   debug2: channel 0: rcvd eow
>>   debug2: channel 0: close_read
>>   debug2: channel 0: input open -> closed
>>   connection hangs at this point
>
> The server is doing the right thing, but the underlying process is not
> terminating when its output it closed.

At this point the child should have exited.  However, if it's  
depending on a SIGPIPE to do so and sshd is using socketpair instead  
of pipe to communicate with it, Bug 85 comes into play and the child  
doesn't get a SIGPIPE as a result of input transitioning from open ->  
closed and so doesn't exit.

>> whereas when it doesn't hang, ssh client log looks like this:
>>
>>   ...
>>   debug2: channel 0: write failed
>>   debug2: channel 0: close_write
>>   debug2: channel 0: send eow
>>   debug2: channel 0: output open -> closed
>>   debug1: client_input_channel_req: channel 0 rtype exit-signal  
>> reply 0
>>   debug1: client_input_channel_req: channel 0 rtype eow at openssh.com
>> reply 0
>>   debug2: channel 0: rcvd eow
>>   ...
>
> Yes, the client signals that its input fd has closed, the server  
> closed
> the output fd of its process and the process exited.
>
>> and sshd log looks like this:
>>
>>   ...
>>   debug1: server_input_channel_req: channel 0 request eow at openssh.com
>> reply 0
>>   debug2: channel 0: rcvd eow
>
> ^^^ this is the client signalling that its input has closed
>
>>   debug2: channel 0: close_read
>>   debug2: channel 0: input open -> closed
>
> ^^^ server closes output of child process
>
>>   debug1: Received SIGCHLD.
>
> ^^^ child process exits

And in this case sshd included the Bug 85 fix and so was using pipes  
to communicate with the child and the child therefore got a SIGPIPE on  
the input open -> closed transition and exited.

Kyle