Bug#158170: rsync: hangs or exits with strange errors when pulling files
Paul Slootman [EMAIL PROTECTED] writes: 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 for the reminder! I was going to try this again and had forgotten about it. I'm pleased to report that with the latest version of rsync, I can no longer reproduce the problem that I was having. Previously, I could reliably hang rsync by syncing a deeply nested directory structure from the remote system to the local system using ssh or rsh as the transport. Both now work fine. It looks like whatever had been causing this was finally fixed. Feel free to close this bug. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#158170: rsync: hangs or exits with strange errors when pulling files
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]
Bug#158170: rsync: hangs or exits with strange errors when pulling files
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]
