severity 476786 important
thanks
On Sat 19 Apr 2008, Laurent Caron wrote:
> I did notice that rsync fails to transfer some files (eg:
> /var/log/ntpstats/*) and dies on files in that directory on any
> non-initial run.
>
> On the first run, it all goes well.
>
> On the subsequent runs:
>
> donald:~# rsync -aAzHRxby -vP --exclude='var/log/ntpstats' --numeric-ids
> --suffix='' --backup-dir=/backup/local/gloups.lncsa.com/2008-04-YY
> 'gloups.lncsa.com:/{etc,var/log}'
> /backup/local/gloups.lncsa.com/current
>
> receiving file list ...
> 14452 files to consider
> ...
> ...
> var/log/ntpstats/
> var/log/ntpstats/loopstats
> 884 100% 1.59kB/s 0:00:00 (xfer#11, to-check=182/14473)
> var/log/ntpstats/peerstats
> 8306 100% 14.97kB/s 0:00:00 (xfer#12, to-check=172/14473)
> zsh: segmentation fault rsync -aAzHRxby -vP --numeric-ids --suffix=''
> rsync: connection unexpectedly closed (120216 bytes received so far) [sender]
> rsync error: error in rsync protocol data stream (code 12) at io.c(453)
> [sender=2.6.9]
> rsync: connection unexpectedly closed (447235 bytes received so far)
> [receiver]
> rsync error: error in rsync protocol data stream (code 12) at io.c(453)
> [receiver=2.6.9]
>
> If i now use an exclude (--exclude='var/log/ntpstats'), it finishes
> without any problem.
You already used that exclude. At least you show you did, although the
output is not consistent with that.
> I did use critical severity because, if you use rsync to make backups...
> it can be messy to realize your backups are just useless.
It is always the administrator's responsibility to check that backups
are made successfully, hence I'm downgrading to "important".
If rsync failed silently, that might be cause for "critical".
Note that I used this version of rsync to backup 150 systems, and I
didn't came across this error. (Those systems have since been upgraded
to rsync 3.0.2.)
I did find something similar when testing the prerelease version of
3.0.0. Strange that you now came across it in 2.6.9...
As it's almost impossible to get a fix for bugs in the stable
distribution, I would like to ask you to try the backport version of
3.0.2, available via http://packages.debian.org/etch-backports/rsync .
Alternatively, if you want to help fix this bug in 2.6.9, you could
download http://debian.wurtel.net/i386/rsync and use that (it's
basically a 2.6.9_2etch2 built without optimization and not stripped).
First do "ulimit -c unlimited", and trigger the bug. You should then
have a core dump. Then do "gdb /path/to/rsync core" and "bt" to get the
stack backtrace. Alternatively make the core dump available to me.
Hopefully that would help pin down the cause of the error.
Thanks,
Paul Slootman
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
