rsync 2.5.6 timeout bug
jw at pegasys.ws
Sat Aug 2 11:13:17 EST 2003
On Sat, Aug 02, 2003 at 01:00:47AM +0100, Alan Burlison wrote:
> Alan Burlison wrote:
> >>That is what really happens. The client specified timeout
> >>is passed over the wire for use by the server but if the
> >>server has a value specified in rsyncd.conf that value will
> >>override the client.
> >OK, right - thanks for the clarification. Still leaves me with the
> >puzzle of why my rsyncs are timing out though... More investigation is
> >obviously needed.
> I've been watching the traffic between the client & server with ethereal,
> and I notice that a lot of the rsync packets are tagged as [short frame],
> although they do have a data payload consisting of a list of filenames
> interspersed with binary data (lengths/checksums I guess). The penultimate
The stuff from stat(2). No checksums yet unless you specified -c.
> pachet sent by the server has a [short frame] tag, and the last packet sent
> by the server looks like it contains the names of a couple of files from
> the top-level directory I am syncing, followed by my string user & group
> ids, followed by 8 nulls.
4 bytes NULL to terminate the gid list. 4 bytes status.
Everything normal so far.
> The next packet back from the client is a ACK,
> followed by FIN, ACK - so it looks like the client is barfing on this last
> packet, as it prints the "error in rsync protocol stream" message.
What should have been sent next (aside from ACK) should have
been a 4 byte integer of a fairly low value followed by some
binary data representing the checksums or 12 bytes of NULL
for a new file.
> Is there any documentation on the rsync protocol?
I don't think so. Only the code. If i recall the comments
of someone else correctly pysync is wire-compatible with
rsync and might be easier to grasp.
> Anyone have any clues as to why this failure might be happening, or how I
> might narrow it down? I was wondering if the packets were being fragmented
> between the client/server, and if that could be causing problems.
Is there any chance there is a firewall enforcing a timeout;
possibly a "personal" firewall on the client machine? If it
were the client code timing out i think there would be an
error message. What you describe looks like the connection
is being closed from the client end, not a timeout in the
J.W. Schultz Pegasystems Technologies
email address: jw at pegasys.ws
Remember Cernan and Schmitt
More information about the rsync