RSYNC Hang on client match_sums

Matt McCutchen hashproduct+rsync at
Fri Aug 31 15:11:08 GMT 2007

On 8/31/07, Alain DESEINE <alain.deseine at> wrote:
> Here is the logs you ask for, in the zip file attached.

I looked at the logs and the hang occurs at the same place, but on the
file tmpal/maj/cygpopt-0.dll .  Here is what happens:

1. The sender writes all 22528 bytes of the file's data to the network at once.
2. This data evidently gets to the receiver fine, because the receiver
reads all 22528 bytes off the network.
3. The sender prepares to send the end-of-file token by selecting for
writing to the network.
4. For some reason, the select call times out instead of reporting
that the network is ready for writing.
5. The receiver attempts to read the end-of-file token off the network
but blocks forever.

To see that #4 is happening, compare the following two sections of
client.strace.log.  Starting at line 13623, we see that the sender
sends the final 2560-byte chunk of the rather large file
tmpal/maj/cygcrypto-0.9.8.dll , successfully selects for writing to
the network (note "testing fd 3" and "write_ready"), and sends the
4-byte end-of-file token.  Starting at line 14105, we see that the
sender sends all 22528 bytes of tmpal/maj/cygpopt-0.dll and selects,
but the select times out.

The end result is that the sender is blocked waiting to write to the
receiver and the receiver is blocked waiting to read from the sender,
which is silly.  The hang is the fault of either Cygwin, Windows, or
the network connection for allowing this situation to arise.  Most
likely, it's another example of the Cygwin pipe/socket hanginess
described here:

As a workaround, you might try setting a --bwlimit as described in
that bug on the one misbehaving host.


More information about the rsync mailing list