Some machines never have this problem. We think it's a hiccup in the network connection -- but it's very minor. We've setup pings and tracked the data sent through the interface and have never seen it drop below 300 bytes / 5 second slice (so we know the connection isn't crashing down on us -- besides, the retry should catch it.)
I have checked the usual culprits and think my next step is to wade into the code (disk space good, timeouts virtually nonexistent, cpu load low, lots of free memory, etc.)
The phase shows unknown, and the call in io.c is simply a write function -- any suggestions on back tracking to find what is calling the write? Maybe we can restart the phase that's failing (kind of like transaction framing for sql -- perform a commit/rollback operation.) It works great, just seems vulnerable to a lost packet somewhere.
Log from "rsync --partial -v -a -z --delete --backup --suffix='.backup' --bwlimit=15 /. 10.1.1.61::/save/":
building file list ... done
etc/cups/certs/0
etc/mail/statistics
etc/mail/logs/092603
rsync: writefd_unbuffered failed to write 16385 bytes: phase "unknown": Connection timed out
rsync error: error in rsync protocol data stream (code 12) at io.c(515)
-- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
