Emergency UNIX and Linux Support

hi guys.

I have configured rsync to make a mirror, but there is an error, I don't understand in the logfile:

Code:

2011/01/18 16:54:25 [3634] rsync on centos/ from UNKNOWN (212.120.196.127)
2011/01/18 15:56:00 [3634] rsync: writefd_unbuffered failed to write 4 bytes [sender]: Connection reset by peer (104)
2011/01/18 15:56:00 [3634] rsync error: error in rsync protocol data stream (code 12) at io.c(1119) [sender=2.6.8]

any idea?

You need to check logs on the far end, to see why your correspondent process took a powder. "Connection reset by peer" can be a remote end socket fd close(), or the implicit close() of an exit(). Look for core files, too, there.

At a higher level, if the rsync is using ssh as a tunneling protocol, then it could be the ssh session timed out or reset. Check with the sshd_config on the other side to see if such a thing is configured. Or if rsync uses its own protocol (rsync daemon), it could be that process ran out of memory. rsync is susceptible to oom errors.

I guess the ssh guys forgot to make an ssync like scp for rcp and ssh for rsh. I have found ssh tunnels a bit troublesome in some cases, yet solid in others. Running out of memory may be shortage of swap for VM, as almost nobody uses RAM directly any more.

I make my mirrors with: find * -newer mark_file -type f|cpio make archive|some compressor|ssh or rsh "matching uncompressor|cpio unpack update only make dirs". It spreads the load out and gives me choice of compressors to match network/CPU speed. I can even split the load up with "find ...|xdemux n '...' ", my dumb mux tool, into N parallel streams. I can add nice to the compressors if there are residents that might need CPU on the sending end. Just create a new mark file and sleep 1 second before starting each run, and when done, make the new mark the next old mark file.

rsync is a good way to make a mirror, as it uses a minimum change-set to copy make sure the two sides have the same contents.

As for the timeout... post more information if you still have the problem: What protocol is rsync using to connect to the remote side? (rsync's own or ssh) Does the problem happen all the time, or just some of the time? Is the "handle files with holes" option in use? If not, make sure you dont copy db/dbm files and the like. Does the problem occur if you do a *local* rsync - using the same host via the loopback connection?