rsync error: error in rsync protocol data stream (Broken pipe)

Nate Case nd at
Tue Jun 17 02:53:04 EST 2003

I'm experiencing some unexpected behavior with rsync v2.5.6.  After
looking around it seems like several people have experienced similar
problems in the past, but those appear to be old bugs that are solved now.
 Also doesn't appear to be any direct bugfixes made for this issue since

The strange thing is that things seem to work when I use ssh for
transport.  However now I need to switch to using the rsync daemon
directly and this problem has arose.

I'm pushing local data to a remote rsync backup server:

# rsync -a -v --modify-window=2 /backup/Source/Dir/
user at xx.xx.xx.xx::backup/dest
building file list ... rsync: writefd_unbuffered failed to write 4092
bytes: phase "send_file_entry": Broken pipe
rsync error: error in rsync protocol data stream (code 12) at io.c(515)

With more -v's, I end up with the same message at the end, but it's
preceeded by a bunch of lines like this (filenames altered):


It stops on the same file each time.  I tried deleting this file to see if
it's just choking on a particular file (or type of file), but in that case
it just chokes on the next file (different type) in the directory.  The
files in this directory are no bigger than 2MB.  If I remove the
subdirectory entirely, it still just dies on the next file it encounters.

The directories that I'm syncing do have a large number of files, but as I
mentioned earlier, it does seem to work when using "-e ssh".  I do not
seem to be running out of memory.  I also tried the same parameters but
breaking it up into smaller subdirectories, and it still failed after X
amount of files with the same error (I did not determine whether or not X
is always the same with using other directories).  Note that this is
always occuring in the "building file list" stage, and not the actual file

After looking at io.c, it seems like the problem (rather, the symptom) for
this error message is a failed write() call (which explains the Broken
Pipe message to stderr).  I thought maybe --blocking-io would avoid this
issue, but it still happened when using --blocking-io.

Does anyone have any ideas about what could be causing this?


- Nate Case <nd at>

More information about the rsync mailing list