On Thu, Oct 19, 2000 at 01:21:15PM -0500, Dave Dykstra wrote:
> On Thu, Oct 19, 2000 at 10:10:33AM -0500, Dave Dykstra wrote:
> > Remarkably, after it was hung for a
> > long time it finally did exit without any error messages. This reminds me
> > of another question/(patch?) somebody posted about hangs right at the end
> > of a run. I looked through the subjects in the mailing list archives for
> > the last three months and it didn't jump out at me; can anybody help me out?
>
> Found it:
> http://lists.samba.org/pipermail/rsync/2000-June/002400.html
>
> That's not it, Tridge put it into rsync 2.4.4, CVS revision 1.113 on main.c.
Furthermore, even though the client exitted without any error messages,
the server did put an error in the rsync_log and it did not complete.
I've now got a way any of you should be able to reproduce this. I have
copied the whole fileset that has been failing for me to samba.org's rsync
server area, and I have got it to fail also when trying to pull from there
to my solaris 7 machine over here. It didn't fail pulling from samba.org
to itself, unfortunately, but perhaps you can try it from another local
machine there or log in to us4.samba.org or something to pull from there.
I duplicated the problem and ended up with a netstat on samba.org of
Proto Recv-Q Send-Q Local Address Foreign Address (state)
tcp 44684 60816 samba.org.rsync host212-140-200~.32445 ESTABLISHED
and on my client
Local Address Remote Address Swind Send-Q Rwind Recv-Q State
dynamic.ih.lucent.com.36930 203.17.0.92.873 1 0 8760 0
ESTABLISHED
The host names don't match up well because I'm coming in through a firewall.
Hmmm, I see this result is different because the send-Q on the client side
is 0; the lock-up I had (over an intranet WAN, not the internet) also had
stuff in the client send Q. I'm running this a second time as I'm
finishing up this message and it hasn't locked up completely yet this time
even though it has hung up at times for over a minute so hopefully I
haven't spoken too soon, or that you can reproduce it within your own LAN.
I have found that it needs both the old set of files and the new. The
old files are found at rsync://samba.org/rsyncftp/rsynctstcmp and the
new files are found at rsync://samba.org/rsyncftp/rsynctst. First I
copy the rsynctstcmp files to a local directory called rsynctstcmp.
You should be able to do this first step with
mkdir rsynctstcmp
rsync -az rsync://samba.org/rsyncftp/rsynctstcmp/ rsynctstcmp/
Next, here's the command that fails:
rm -rf rsynctst;mkdir rsynctst
rsync -az --compare-dest `pwd`/rsynctstcmp/ \
rsync://samba.org/rsyncftp/rsynctst/ rsynctst/
Alternatively I think you could pre-populate your "rsynctst" directory
with the rsynctstcmp files, but I haven't tried it that way because it
was more convenient to keep them in a separate place so I could repeat
the test.
By the way, the "rsynctstcmp" directory happens to be most of a solaris
installation of mozilla M17, and "rsynctst" is M18.
Those of you on the rsync mailing list, note that the link to samba.org is
an expensive wireless link that is often saturated so it's probably not a
good idea if a lot of you try to duplicate this. These instructions are
primarily for Tridge & Martin.
Have a good day down under, I'm going home.
- Dave Dykstra
