ssh host echo bla | echo bla

[Nicolas Williams]

On Wed, Dec 19, 2001 at 12:51:55AM +0300, Michael Tokarev wrote:
> Nicolas Williams wrote:
> > 
> []
> > > connection attempt if e.g. stdout is closed.  That to say -- I think that
> > > ssh should "reinvent" the -1 behaviour (correct from my view) to -2 variant
> > > (i.e. do what it was asked for and print any error message), but NOT the
> > > reverse.
> > 
> > Why not? I think exiting when stdout or stderr are broken is fine, as
> > long as it's documented. :)
> 
> Because it is (sometimes) legal action to do -- to run ssh w/o stdout, that
> is.  If ssh is transparent (i.e. it runs commands on the remote just like

If I want to run ssh without stdout I redirect its stdout to /dev/null,
NOT to a broken pipe. I don't think it's useful to use a broken pipe on
purpose as the stdout of anything. If ssh can't output because stdout is
broken then, IMHO, it should try to log an error message to stderr and/or
syslog and then exit.

> if them are running on a local box), then let it be transparent.  If it is
> ok to say "echo foo | echo bar" on a local box (while stupid), it should be
> the same with ssh (and with the error messages and exit codes).  Remote
> command may not produce anyhing -- and not having a valid stdout isn't a
> reason to skip running it at all.

/bin/od /kernel/genunix | /bin/true

exits right away on Solaris (sooner than "/bin/od /kernel/genunix|wc").

/bin/od /dev/zero | /bin/true

hangs on Solaris - /bin/od sits there reading and reading - never
writing.

ssh -v -v -v -2 somehost /bin/od /kernel/genunix | /bin/true

hangs on Solaris and here's the key bit of the stderr output:

...
debug1: Sending command: /bin/od /kernel/genunix
debug2: callback done
debug1: channel 0: open confirm rwindow 0 rmax 16384
debug2: channel 0: rcvd adjust 32768
debug1: channel 0: write failed
debug1: channel 0: output open -> closed
debug1: channel 0: close_write
<hang>

I think that ssh should have: a) printed an error message to stderr (and
syslog, if that failed) when "debug1: channel 0: write failed" and b)
exited.

With "ssh -v -v -v -2 somehost /bin/od /dev/zero | /bin/true" the hang
occurs because ssh never has a reason to print to stdout BECAUSE /bin/od
/dev/zero DOESN'T PRINT ANYTHING, so ssh never finds out that stdout is
broken, and then there's nothing special for it to do.

SIGPIPE and EPIPE are produced synchronously - i.e., when ssh writes to
stdout - so if ssh doesn't write to stdout it can't know that stdout is
broken.

> BTW, on linux even,
> 
>   cat /dev/zero | true
> 
> will NOT produce any error message, but

See above. /bin/od apparently wants to summarize all the nulls in the
input, so /dev/zero is a bad candidate for this test.

>  (cat /dev/zero; echo $?) | true

(/bin/od /kernel/genunix; print -u2 $?)|/bin/true
141

on Solaris.

(/bin/od /dev/zero; print -u2 $?)|/bin/true      

hangs, on Solaris. Again, /bin/od and /dev/zero - bad test case.

> also NOT prints anything -- subshell in () was killed by SIGPIPE
> (if memory serves me correctly, the same will print something
> sensitive/useful on solaris).  But if the same will be called from
> a e.g. perl program with proper redirections, perl will be able to
> detect that first process killed (by SIGPIPE) and not exited normally.

Default action for SIGPIPE is ignore, I think.

> > Deadlocking is not.
> 
> Yes, obviously.

Right. See above. OpenSSH notices the broken stdout and does nothing and
that's the reason for the hang and the problem altogether.

> Regards,
>  Michael.


Cheers,

Nico
--
-DISCLAIMER: an automatically appended disclaimer may follow. By posting-
-to a public e-mail mailing list I hereby grant permission to distribute-
-and copy this message.-

Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.