Connection Reset by peer

[Martin Pool]

On 10 Apr 2002, David BORDAS <bordas at 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