rsync - Apr 2002 - Connection Reset by peer

Hi all,

all night i'm backuping around 15 Go from some of our serveurs connected to
internet.
My backup server and all web servers aren't on the same town and all are
connected to internet so i use rsync for backuping.

I also use rsync for replication between all web servers without any
problem.

During this backup (all night ) i've can see "rsync: read error:
Connection
reset by peer" in client's error logs.

All server are running rsync 4.6.xx installed from a red-hat rpm.
All OS are Linux red hat on intel platform.

On client i tried the same rpm, or several tar.gz version from 4.6.2 to
4.5.5.

I've also tried the "Patch to avoid 'Connection reset by peer'
error for
rsync on cygwin" found in the list.
I know that i'm not using cygwin but i won't to give it a try withou any
luck ...

Client is like this : intel celeron 600 + 256 Mo of SDRAM and 2 * 30 Go
7200tr UDMA drives.
All drive have at least 15 Go free space.
Internet connection : 1.2Mb ADSL permanent.

The most common "Connection reset by peer" appear when backuping big
text
files like SQL dump.
Each dump is around 600MB.

All server are running rsync as a daemon and client is connecting to rsync
like this :
/usr/local/bin/rsync -avrpogtzH --timeout=3600 XXX.XXX.XXX.XXX::backup
/unit2/backup/

I also have a look to rsync daemon error log on server and i can see
something like this :
<< 2002/04/10 04:50:47 [28350] transfer interrupted (code 11) at
main.c(295)
2002/04/10 04:56:59 [26821] transfer interrupted (code 30) at io.c(65) >>

The backup process is launched from a shell script calling rsync one after
the other.
This script is in root crontab.

Thanks
David

On 10 Apr 2002, David BORDAS <bordas@jeuxvideo.com> wrote:
> All server are running rsync 4.6.xx installed from a red-hat rpm.
> All OS are Linux red hat on intel platform.
> 
> On client i tried the same rpm, or several tar.gz version from 4.6.2 to
> 4.5.5.
I suppose you mean 2.4.6 and 2.5.5?
> I've also tried the "Patch to avoid 'Connection reset by
peer' error for
> rsync on cygwin" found in the list.
> I know that i'm not using cygwin but i won't to give it a try
withou any
> luck ...
> 
> Client is like this : intel celeron 600 + 256 Mo of SDRAM and 2 * 30 Go
> 7200tr UDMA drives.
> All drive have at least 15 Go free space.
> Internet connection : 1.2Mb ADSL permanent.
> 
> The most common "Connection reset by peer" appear when backuping
big
> text files like SQL dump.  Each dump is around 600MB.
> 
> All server are running rsync as a daemon and client is connecting to rsync
> like this :
> /usr/local/bin/rsync -avrpogtzH --timeout=3600 XXX.XXX.XXX.XXX::backup
> /unit2/backup/
> 
> I also have a look to rsync daemon error log on server and i can see
> something like this :
> << 2002/04/10 04:50:47 [28350] transfer interrupted (code 11) at
main.c(295)
> 2002/04/10 04:56:59 [26821] transfer interrupted (code 30) at
> io.c(65) >>
Code 11 is "IO error", code 30 is "timeout".  (2.5 gives
better error
messages including this text.)

So it seems the server suspects a timeout or disk/network io error,
and is closing the connection.  Unfortunately it is a bit hard to tell
from here what exactly is causing those errors to occur.  (Better
error reporting is a priority for me in the near future.)

You could try installing 2.5.5 on the server, perhaps running on a
different tcp port using the --port option.

You could also use the --partial option.  Repeated partial transfers
might get the whole file across even if there are network problems.

If you want to do get your hands dirty:

You can use a debugging tool on the server to find more information
about what is going wrong, which will help us fix rsync and resolve
your problem.  After rsync has started on the server, please find it's
pid from "ps", and then do

  strace -o /tmp/rsync.trace -f -p PIDOFRSYNC

Try to find the relevant failure in that file (probably near the end)
and send it a short section through to the list.

Alternatively, you could attach to rsync with gdb and set a breakpoint
on _exit_cleanup.  The "where" command will then show some useful
information.

  $ gdb
  (blah blah)
  gdb> attach PIDOFRSYNC
  gdb> break _exit_cleanup
  gdb> continue
  (wait)
  gdb> where

-- 
Martin