another data point re: asymmetric route problem

[Adam McKenna]

Well, the route to my other secondary dns server recently became asymmetric,
and, as expected, the rsyncs between the primrary and that box are hanging
now, too.

I can not rsync files between my primary DNS server and either of my
secondaries now.  Has there been any progress in solving this problem?

--Adam

-- 
Adam McKenna [EMAIL PROTECTED] | Help stop animal abuse at Petco!
http://flounder.net/publickey.html   | http://www.mickaboofriends.org
GPG: 17A4 11F7 5E7E C2E7 08AA|
 38B0 05D0 8BF7 2C6D 110A|

Re: reproducible problem w/ rsync asymmetric routes

[Adam McKenna]

On Fri, Jun 22, 2001 at 04:09:19PM -0500, Dave Dykstra wrote:
 Those versions are recent enough.  Try Wayne Davison's nohang patch at
 http://www.clari.net/~wayne/rsync-nohang.patch

I just applied the patch and recompiled.  No change in results.

 Presumably the transfer is hanging for a period of time before it times out.
 If Wayne's patch doesn't fix it, check the state of the TCP queues during
 the hang by running netstat on both sides and looking to see if there
 are things sitting in the send queue on one side or the other for that
 connection.

There are 5839 bytes waiting in the SendQ on the sending side for each
connection.

64.71.162.66.56108   206.26.162.146.22 6432   5839 24820  0
CLOSE_WAIT
64.71.162.66.56111   206.26.162.146.22 6432   5839 24820  0
CLOSE_WAIT
64.71.162.66.56114   206.26.162.146.22 6432   5839 24820  0
ESTABLISHED

Running with rsync -ave ssh -v gets me this far:

[...]
debug1: Received RSA challenge from server.
debug1: Sending response to host key RSA challenge.
debug1: Remote: RSA authentication accepted.
debug1: RSA authentication accepted by server.
debug1: Sending command: rsync --server -vlogDtpr . /etc/tinydns
debug1: Entering interactive session.
building file list ... done
[hang]

I created a script /tmp/rsync, on the receiving side, which looks like this:

#! /bin/sh
strace /usr/bin/rsync $@ 2/tmp/rsync.log

and ran truss rsync -ave ssh -v --rsync-path=/tmp/rsync /etc/tinydns/root
[EMAIL PROTECTED]:/etc/tinydns 2/tmp/rsync-truss-sender.txt on the
sending side.

I've posted the complete truss/strace outputs at
http://flounder.net/rsync-truss-sender.txt
http://flounder.net/rsync-strace-receiver.txt

--Adam

-- 
Adam McKenna [EMAIL PROTECTED] | No matter how much it changes, 
http://flounder.net/publickey.html   |  technology's just a bunch of wires 
GPG: 17A4 11F7 5E7E C2E7 08AA|  connected to a bunch of other wires.
 38B0 05D0 8BF7 2C6D 110A|  Joe Rogan, _NewsRadio_
 11:31pm  up 19 day(s), 23:34,  8 users,  load average: 0.07, 0.08, 0.07

Re: Does rsync close open files?

[Adam McKenna]

On Fri, Jun 01, 2001 at 08:44:18AM -0500, Dave Dykstra wrote:
 There is really no way around that problem with rsync.  Many other people
 have tried to do similar things and the wisdom on the mailing list has
 always been that rsync via cron is the wrong tool for applications that
 have data that changes frequently and needs to be replicated very soon
 after it changes. You need something more like a distributed database or a
 replicating filesystem, or at the very least call rsync in a synchronous
 manner right after a file has been changed and before the file can change
 again.

Actually, that's not our situation.  These files will not be changing -- they
just need to get from the FTP machine over to our application server after
they've been uploaded.

Has anyone tried running rsync under djb's svscan?  I'm envisioning a run 
script that looks something like this:

#!/bin/sh
PATH=...
find path -type f -mmin +0 -print  file-list
rsync --exclude=/* --include-from=file-list ...
sleep 60

The only problem in this scenario is if the rsync process somehow hangs, then
it would never be restarted and would require manual intervention.  Anyone
have suggestions for this?

Thanks to the others who replied.

--Adam