Error in rsync protocol data stream (code 12)

[gabier]

I have a "new" NAS4Free server. The RAID1A array is empty and I am trying to backup my data from my desktop Win7/Cygwin to the NAS4Free server via rsync.

Code: Select all

#!/bin/bash
rsync -avz --delete /cygdrive/F/Backup/D83_2012-Jan ggadmin@nas4free:/mnt/RAID1A/ggadmin/backup/  >>/home/ggadmin/gglog.txt 2>>/home/ggadmin/gglog.txt
date>>/home/ggadmin/gglog.txt

The backed-up data directory is quite big (about 20 Gb), but the scenario is always the same:
rsync starts, asks for password, tranfers the incremental file list, and starts the transfer of he files, but it stops after a few tens of files (sometimes a few hundreds), with alwxays the same error:

Code: Select all

rsync: writefd_unbuffered failed to write 4092 bytes to socket [sender]: Broken pipe (32)
rsync: connection unexpectedly closed (194 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at /usr/src/ports/rsync/rsync-3.0.9-1/src/rsync-3.0.9/io.c(605) [sender=3.0.9]

This error is not uncommon. A google search gives some ways to find out what is going on, but in a somewhat specialist langage (rsync site).

Code: Select all

3.Q: Why does my transfer die with something like the following error? 
rsync: error writing 4 unbuffered bytes - exiting: Broken pipe
rsync error: error in rsync protocol data stream (code 12) at io.c(463)
or 
rsync: connection unexpectedly closed (24 bytes read so far)
rsync error: error in rsync protocol data stream (code 12) at io.c(342)

A: This error tells you that the local rsync was trying to talk to the remote rsync, but the connection to that rsync is now gone. The thing you must figure out is why, and that can involve some investigative work. 

If the remote rsync is a daemon, your first step should be to look at the daemon's log file to see if it logged an error explaining why it aborted the transfer. Also double-check to ensure that the log file is setup right, as a wrong "log file" setting in your rsyncd.conf file can also cause this problem. 

Beginning with version 2.6.3, rsync now does a better job of retreiving the error from the remote process than older versions of rsync, so you may wish to try upgrading and see if you now get sent the error message from the remote rsync. 

There are several common causes for a remote rsync process going away: 
◦The destination disk is full (remember that you need at least the size of the largest file that needs to be updated available in free disk space for the transfer to succeed). 
◦An idle connection caused a router or remote-shell server to close the connection. 
◦A network error caused the connection to be dropped. 
◦The remote rsync executable wasn't found. 
◦Your remote-shell setup isn't working right or isn't "clean" (i.e. it is sending spurious text to rsync). 

If you think the problem might be an idle connection getting closed, you might be able to work around the problem by using a --timeout option (newer rsyncs send keep-alive messages during lulls). You can also configure ssh to send keep-alive messages when using Protocol 2 (look for KeepAlive, ServerAliveInterval, ClientAliveInterval, ServerAliveCountMax, and ClientAliveCountMax). You can also avoid some lulls by switching from --delete (aka --delete-before) to --del (aka --delete-during). 

If you can't figure out why the failure happened, there are steps you can take to debug the situation. One way is to create a shell script on the remote system such as this one named "rsync-debug". You would use the script like this: 
rsync -av --rsync-path=/some/path/rsync-debug HOST:SOURCE DEST
rsync -av --rsync-path=/some/path/rsync-debug SOURCE HOST:DEST

This script enables core dumps and also logs all the OS system calls that lead up to the failure to a file in the /tmp dir. You can use the resulting files to help figure out why the remote rsync failed. 

If you are rsyncing directly to an rsync daemon (without using a remote-shell transport), the above script won't have any effect. Instead, halt the current daemon and run a debug version with core-dumps enabled and (if desired) using a system-call tracing utility such as strace, truss, or tusc. For strace, you would do it like this (the -f option tells strace to follow the child processes too): 
ulimit -c unlimited
strace -f -t -s 1024 -o /tmp/rsync-$$.out rsync --daemon --no-detach

Then, use a separate window to actually run the failing transfer, after which you can kill the debug rsync daemon (pressing Ctrl-C should do it). 

If you are using rsync under inetd, I'd suggest temporarily disabling that and using the above daemon approach to debug what is going on. 

My problem is that I do not understand this text enough (I do not even know where the log files are). Could somebody who knows NAS4Free and rsync better than I do give me the beginning of the 'how to' debug this problem ?

gabier

[gabier]

Hi,
I found the log files, and found no error in them.
Then I looked more carefully to the known cases of breakdown of the rsync protocol, and one of them is "disk full". In fact the RAID disk was empty but improperly set up. I dismounted and deleted all disks and reinserted them from scratch.
With this new RAID array rsync could be executed without any error.
In fact this breakdown of the rsync dialog can have many different causes. For those who know a little how nas4free is organized I recommend the document in my first post to debug such an error.

gabier