On Tue, May 29, 2001 at 11:36:11AM -0400, Tuc wrote:
> >
> > I don't have any experience with BSDI, but what's the full command line of
> > the rsync command you're trying to run?
> >
> /usr/local/bin/rsync -vrlptgozx --partial --delete --force
> --rsync-path=/usr/local/bin/rsync --exclude='stats/' --exclude='archive/'
> --include='*/' --blocking-io /usr/home/directory/subdirectory/
> [EMAIL PROTECTED]:/usr/home/directory/subdirectory/
I don't know what to tell you. You seem be doing the right things,
although --blocking-io is default if you don't set the transport command
with -e to something other than the default, which is "remsh" if it existed
at configure time, otherwise "rsh". Perhaps it is a BSDI-specific
problem. You could try turning off blocking-io by setting the -e command
to a full path to rsh, because the test for turning on blocking-io compares
exactly to the string without the full path.
Can you reliably cause the problem to go away when you go back to 2.3.1 and
re-appear when you go to 2.4.6? The main difference between the two
versions is that a buffering hack was removed in version 2.4.0 that was
supposed to only affect ssh, and instead non-blocking I/O was implemented
for use with ssh.
Rsync tends to greatly stress TCP implementations, and has brought to light
bugs in many of them. When rsync is hung, we often ask that people run
"netstat" on both sides to look at the TCP queues for the rsync connection.
If there is data on the send queue on one or both sides while it is hung,
TCP is at fault because it is TCP's responsibility to get data from the
send queue on one side to the receive queue on the other.
- Dave Dykstra
