stderr pipe not closed when cancelling session on shared connection
jjelen at redhat.com
Thu Oct 1 19:39:01 AEST 2015
On 09/29/2015 06:50 PM, Stephane Chazelas wrote:
> when investigating an issue with gitolite
> I realised that when you do
> # Create a master connection
> ssh -MnNfS ~/.ssh/ctl localhost
> # Reuse that shared connection to run a command on the host
> ssh -S ~/.ssh/ctl localhost 'cat; yes >&2'
> And then press Ctrl-C, sshd does close the stdin and stdout pipe
> to the remote shell (so cat returns after seeing eof on stdin),
> but not the stderr pipe.
> That next "yes" command does fill up the stderr pipe, and
> looking at strace output, at the other end of the pipe, sshd is
> not reading from it.
> If I kill that "yes" command, "bash" hangs again trying to write
> a "job killed" message on stderr.
> If I kill "bash", I can see sshd returning from a waitpid(),
> doing *one* read (of 16384 bytes) from that stderr pipe (put
> doesn't do anything with the data read) and closes that last
> It seems to me that if sshd is not going to do anything with
> that pipe, it should close it as soon as it becomes impossible
> to send the data to the client like it does for the stdout pipe.
> In the case of gitolite, gitolite was writing a character to
> stderr upon EOF to force a SIGPIPE delivery when the ssh
> connection is aborted. While that works for a normal ssh
> connection, that does't work for one using a shared connection.
> Reproduced with:
> OpenSSH_6.9p1 Debian-2, OpenSSL 1.0.2d 9 Jul 2015
> OpenSSH_7.1p1, OpenSSL 1.0.1f 6 Jan 2014
The issue is wider than you describe. There is bug #52  which was
causing hang for a long time and fix for this issue brought your
described behavior and bug #2071 , where is similar reproducer even
without connection multiplexing. I was trying to figure out what is
going on there and what could be the best solution, but so far without
any great success.
More information about the openssh-unix-dev