Russ, do you still have problems with the current (2.6.9) version of rsync? If so, please see Wayne's advice below for further debugging.
Thanks, Paul Slootman On Fri 10 Feb 2006, Wayne Davison wrote: > Russ: your strace output didn't list the 3rd rsync process (there are > two processes on the receiving side and one on the sending side). Also, > the "issues and debugging" page of the rsync website has some hints to > help debug problem scenarios, such as including what "netstat" says > about active socket connections and their send/receive buffers. You > might also try using --blocking-io or --no-blocking-io to see if that > makes any difference (using --blocking-io fixed one situation recently). > > Richard wrote: > > /usr/bin/rsync --no-detach --daemon --config /etc/rsyncd.conf > [...] > > rsync -a fs1::remote-name/ /localfilesystem/path/ > [...] > > rsync error: timeout in data send/receive (code 30) at io.c(181) > > The only way a timeout can occur without a client-specified --timeout > option is if the daemon's config file specifies a timeout, and that can > be problematical if it is too short to allow for any dead-time that can > occur during the transfer of a large file (what is it's setting?). The > current protocol does not allow the daemon to tell the client about a > timeout setting, so the client can't help to prevent a timeout unless > there is also a command-line --timeout option specified (which should be > less-than or equal-to the daemon's timeout setting). If timeouts still > occur with a long timeout value, treat the situation as a hang and get > some strace output of the 3 processes and the netstat output when the > connection stalls so that we can try to figure out what might be wrong. > > ..wayne.. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
