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]
