rsync 2.6.3 hang (was rsync 2.6.2 crash)
jim at thegallaghers.biz
Tue Oct 5 20:59:22 GMT 2004
Thanks for the additional info.
I actually have tried the --no-blocking-io option, but the sync still hung.
Since no one on Unix-like platforms are reporting an issue, do you think it may be
something in the Cygwin compatibility layer?
Interestingly (to me anyway,) is that I have encountered the problem with syncing
across the network using ssh, and syncing locally, but not over the network
rsync to rsync. Maybe it's just a matter of time....
> From: Wayne Davison <wayned at samba.org>
> Subject: Re: rsync 2.6.3 hang (was rsync 2.6.2 crash)
> Sent: 05 Oct 2004 10:06:15
> On Tue, Oct 05, 2004 at 07:07:17AM -0700, jim wrote:
> > Can you explain to me the relationship between the parent rsync
> > process and it's children?
> Rsync has a separate process for each major function.
> The generator process (on the receiving side) has the job of figuring
> out which files are different and sending checksum data for all the
> files it wants to see updated. It sends that data to the sender.
> The sender has the job of taking the checksum data and generating a
> stream of data that can be used to recreate the sender's file using the
> receiver's file as a source of data. It talks to the receiver process
> (which is on the same system as the generator, and which actually
> spawned the generator when things were starting up).
> The receiver has the job of taking the update data from the sender and
> turning it into the final updated files. The final bit of communication
> is that the receiver has a pipe between it and the generator that can be
> used to send the generator some messages that need to be forwarded to
> the sender (since it can't send things to the sender directly).
> All these channels are selected for reading and writing using the
> select() function. Most of the processes are in a constant state of I/O
> blocking, which is just fine going from the generator to the sender to
> the receiver. However, the channel from the receiver to the generator
> has to be kept unblocked by buffering any messages that appear so that
> rsync doesn't deadlock. That should all be handled just fine unless
> there is a bug.
> In the trace output you sent, it looks like the sender is waiting to
> write to the socket, the receiver is waiting to read from the socket,
> and the generator is waiting simultaneously on reading the pipe and
> writing the socket, so I don't see anything wrong there.
> One thing you might try is specifying --no-blocking-io and see if that
> makes a difference in the hanging you're seeing.
More information about the rsync