rsync 2.5.4 (probably 2.5.5 too) server handles SIGPIPE very poorly

[Colin Walters]

[resent by mbp]

On Tue, 2002-05-28 at 10:22, Jonathan Kamens wrote:

> If you run rsync with a subshell through ssh.com's ssh and sshd and
> then kill the client with ctrl-C, the rsync server process running on
> the remote machine grows without bound and eventually completely hoses
> the machine.

I feel some responsiblity for this, because it was my patch (to solve
another, but similar problem) which caused rsync to ignore SIGPIPE.

>   When the client rsync and ssh exit, and thus sshd on the other end
>   exits, and then the server rsync tries to write to the client, it
>   gets SIGPIPE.  Alas, SIGPIPE is being ignored, because, quoting a
>   comment in the rsync source code, "Ignore SIGPIPE; we consistently
>   check error codes and will see the EPIPE."
> 
>   The comment is wrong; it does *not* see the SIGPIPE.  

I assume you mean it doesn't see the EPIPE.  SIGPIPE is ignored, so we
won't see it.

>   What happens
>   is that as a result of the SIGPIPE

You mean as the result of the EPIPE return code.

> exit_cleanup gets called.
>   That's a macro which calls _exit_cleanup.  That calls log_exit That
>   calls rwrite.  Rwrite tries to write an error to stderr, but that
>   fails because of (you guessed it!) SIGPIPE, and so rwrite calls
>   exit_cleanup.  Presto, an infinite loop is born.

This analysis appears to be correct.

>   The most straightforward fix I came up with is to modify rwrite so
>   that it doesn't actually try to write the error if the FILE to which
>   the error has been written is showing a true error condition
>   (checked with ferror).  I will attach a patch.

I think a better solution is to create a new function
exit_cleanup_nolog, which will prevent exit_cleanup from logging
anything.  The attached patch implements that, and changes that section
of log.c to use it. There are probably other places that should be
changed to use it as well.

>   I suspect that the rsync server running under openssh doesn't have
>   this problem because openssh sshd causes it it to get a SIGHUP
>   whereas the ssh.com version of sshd does not.  

You should be using OpenSSH anyways; the ssh.com version of ssh is
proprietary software.

Could you test the attached patch?


-------------- next part --------------
A non-text attachment was scrubbed...
Name: rsync-log.patch
Type: text/x-patch
Size: 3563 bytes
Desc: not available
Url : http://lists.samba.org/archive/rsync/attachments/20020602/5823f446/rsync-log.bin