Bill Rugolsky Jr.
2003-Aug-22 21:24 UTC
Client does not propagate EPIPE write error to server.
Hi, I'm experiencing the bug reported in: http://bugzilla.mindrot.org/show_bug.cgi?id=85 Bugzilla Bug 85 ssh -2 localhost od /bin/ls | true ignore SIGPIPE Perhaps a slightly more realistic example: rugolsky at mercury: ssh -vvv -x -n -2 localhost cat /dev/zero | dd count=1 ... debug1: fd 4 setting O_NONBLOCK debug1: fd 5 setting O_NONBLOCK debug1: channel 0: new [client-session] debug3: ssh_session2_open: channel_new: 0 debug1: send channel open 0 debug1: Entering interactive session. debug2: callback start debug1: ssh_session2_setup: id 0 debug1: Sending command: cat /dev/zero debug1: channel request 0: exec debug2: callback done debug1: channel 0: open confirm rwindow 0 rmax 32768 debug2: channel 0: rcvd adjust 131072 debug1: channel 0: read<=0 rfd 4 len 0 debug1: channel 0: read failed debug1: channel 0: close_read debug1: channel 0: input open -> drain debug1: channel 0: ibuf empty debug1: channel 0: send eof debug1: channel 0: input drain -> closed 1+0 records in 1+0 records out debug1: channel 0: write failed debug1: channel 0: close_write debug1: channel 0: output open -> closed and hangs ... It seems that with v2, EOF on input descriptors are propagated to the peer as EOF, but there is no corresponding protocol mechanism in the v2 protocol for indicating that an output file descriptor is closed? Is this correct? If so, it seems horribly broken. The v1 code sets quit_pending=1, and exits the select loop. I have a hack that does something equally ugly for v2 by creating a channel state notifier callback, and only registering it for the session_ident in the clientloop setup. Any better ideas? Please CC me, as I'm not subscribed. Regards, Bill Rugolsky