[ILUG] Strange rsync issues

[Paul Murray]

Sorry for the top post, but if your MUA wrapped its lines at a
sensible length, then it would quote cleanly, which it currently
doesn't.

My broadband goes down at 1am religously every night, it changes with
the clock change. I'll bet thats your issue with the first cronned
rsync failing at 1am and the subsequent ones passing, and all passing
if you stall it for 8mins. It typically takes no more than 30 seconds
for a broadband connection to resync and establish a ppp connection.

Paul.

On Mon, Jan 25, 2010 at 11:49 AM, Brian O'Mahony
<brian.omahony at curamsoftware.com> wrote:
> Andrew
>
> There is nothing in either hosts.allow or hosts.deny on either server. They are both using the same nameserver (in dublin). Here is a little more information for clarity.
>
> The server in BLR is pulling data from the server in dublin. It is synching 8 different folders at about 1am Irish time. The first rsynch fails, and the further seven complete.I added the first rsynch to the crontab again about 8 mins later, and it DOES complete, even though the first one still fails. Also this has been running for at least four years without problems. I only picked up on the errors in the last few weeks, but when i checked the date on the rsynchs i was probably a day or two behind.
>
> Hope that is more information to go on.
>
> I will try your ideas later today.
>
> B
>
> ________________________________________
> From: Andrew McGill [list2009 at lunch.za.net]
> Sent: 22 January 2010 21:30
> To: ilug at linux.ie
> Cc: Brian O'Mahony
> Subject: Re: [ILUG] Strange rsync issues
>
> ---
>> Anyone have any ideas?
> I'll bet the receiving server is doing a tcpwrappers check.  I'll guess your
> hosts.deny says to be unfriendly, and /etc/hosts.allow says:
>
>        sshd: server.bangalore.in
>
> When you connect from bangalore, tcpwrappers does the rough equivalent of:
>     dig -x 88.88.88.88  (which hopefully says server.bangalore.in)
>     dig server.bangalore.in (which hopefully says 88.88.88.88)
>
> One of these DNS requests is probably failing.  When the DNS lookup is
> retried, the cached results from the first previous query allow the lookup to
> complete.  The problem may be with the DNS registration itself -- some of the
> NS servers in the chain may fail to respond (squish.net has a nice checker).
> You  may also have a poor or incorrect nameserver configured in resolv.conf.
>
> You can use an IP address in hosts.allow, check your DNS server, create a
> /etc/hosts entry :) or hack it by making a connection to almost any port that
> will trigger a reverse DNS check.
>
>>
>> B
> &:-)
>
>
> The information in this email is confidential and may be legally privileged.
> It is intended solely for the addressee. Access to this email by anyone else
> is unauthorized. If you are not the intended recipient, any disclosure,
> copying, distribution or any action taken or omitted to be taken in reliance
> on it, is prohibited and may be unlawful. If you are not the intended
> addressee please contact the sender and dispose of this e-mail. Thank you.
>
> --
> Irish Linux Users' Group mailing list
> About this list : http://mail.linux.ie/mailman/listinfo/ilug
> Who we are : http://www.linux.ie/
> Where we are : http://www.linux.ie/map/
>