wmoran at collaborativefusion.com
Mon Jan 22 21:25:21 UTC 2007
In response to Peter Pluta <peter at placidpublishing.net>:
> Peter Pluta wrote:
> > I have a win2k3 server running as my rsync server. I also have a
> > freebsd web server being the rsync client. A shell script runs every
> > night at 5am (it's below).
> > Shell script:
> > #!/bin/sh
> > . `dirname $0`/settings.inc
> > destination=**.***.***.***::backup
> > if [ "$TERM" ]; then verbose=-v; fi
> > rsync $verbose -azR --delete-after /usr/local/etc/ $destination
> > rsync $verbose -azR --delete-after /usr/local/lib/sasl2/ $destination
> > rsync $verbose -azR --delete-after /var/cron/ $destination
> > rsync $verbose -azR --delete-after /root/ $destination
> > rsync $verbose -azR --delete-after /etc/ $destination
> > rsync $verbose -azR --delete-after --exclude httpd-*.log $wwwDir/
> > $destination
> > After it runs for 5 minutes it throws this:
> > rsync: writefd_unbuffered failed to write 16385 bytes [sender]: Broken
> > pipe (32)
> > rsync: read error: Connection reset by peer (54)
> > rsync error: error in rsync protocol data stream (code 12) at
> > io.c(613) [sender=2.6.9]
> > Dmesg on the box only shows this:
> > em0: promiscuous mode enabled
> > em0: promiscuous mode disabled
> > But that is probably pretty old.
> > What can the problem be? backups are really important to me and they
> > don't currently work as the transfer times out after the first few files.
> > Anyone got an idea? Any feedback or suggestions would be greatly
> > appreciated.
I don't know what your problem is, but I can make some recommendations
on debugging it.
*) Are you running it verbosely when this happens? Crank the verbosity
up as high as it will go on both the client and the server and see if
anything shows up. Is the a DEBUG option available if you recompile?
*) Got any network monitoring stuff available? Heavy packet loss?
*) Try ktracing the process while it's running. Should narrow down
the cause a good bit. Or maybe attach gdb to it.
*) Try rsycing to a local directory to see if it still happens. That
should narrow the problem down to either network or not.
*) fsck your disks?
Hope some of this is helpful. Generally, when I have mystery errors,
I start with ktrace. If you're not familiar with it, ktrace can be a
bit overwhelming, but it's got lotsa useful information. Same can be
said for gdb.
Collaborative Fusion Inc.
More information about the freebsd-questions