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

[Jonathan Kamens]

>  From: Colin Walters <walters at gnu.org>
>  Date: 02 Jun 2002 23:51:50 -0400
>  
>  >   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 don't agree that this is a better solution, especially given your
comment in the last sentence above.

What do you think is wrong with my solution?  It solves the problem
exactly where it is likely to be a problem and it transparently solves
all instances of the problem, whereas with your solution, everybody
calling exit_cleanup forever has to worry about whether they're
calling the right one (and you may not have even solved the problem
for all the existing code, let alone for new code written later).

Why put that burden on the programmer forever when you can just make
rwrite handle the problem correctly in all cases?

I have been running with the patch I sent ever since I sent it, and it
works like a charm.

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

If I had a choice about this, I would.  My employer has chosen to use
ssh.com's version rather than OpenSSH.  I do not have the influence to
convince the relevant decision-makers to switch to OpenSSH.

And while it's true that ssh.com's version is in some respects
prioprietary, they give away the source code for free and allow it to
be used for free on Linux.

>  Could you test the attached patch?

I'd rather not do that until you explain why it is that you think your
solution is better than mine.  Since rsync has already hosed one of
our production machines at work several times as a result of this bug,
I'm somewhat reluctant to test something that may still manifest the
bug in some cases, especially when the solution I've already got works
great.

  Jonathan Kamens