jw at pegasys.ws
Fri Feb 13 23:51:02 GMT 2004
On Fri, Feb 13, 2004 at 03:04:21PM -0700, David S. Ahern wrote:
> A google search on this problem did not show any matches, so I'll take
> the chance that someone on this list might consider it an rsync problem.
> In a nutshell, if rsync forks a child process to handle the transport
> (rsh in this case) it can hang in wait_process() forever waiting for
> that child process to die. Normally this would not be a problem.
> However, if the wrong packet is dropped (and all of its retries) it is a
> In the particular case that I have been debugging, the TCP FIN packet
> from the rsh server is not getting received by the rsh client which
> rsync started to send files to a peer. This means that rsh blocks
> indefinitely which in turn keeps rsync in the wait_process loop -- even
> though all files have been transferred.
> Yes, I realize the process that kicks off rsync should ensure that it
> terminates in a timely manner. However, I would like to propose a change
> to rsync that would let invocations of rsync with a timeout die based on
> that timeout: wait_process() could call check_timeout() before calling
> msleep(). When the timeout has been exceeded, rsync would call
> _exit_cleanup and kill_all would take care of the child. You could make
> this check optional so that only calls from client_run do the check.
> just a thought.
J.W. Schultz Pegasystems Technologies
email address: jw at pegasys.ws
Remember Cernan and Schmitt
More information about the rsync