exit status 12 when transferring a large file

Mon Feb 24 21:07:00 EST 2003

--- Erhalten von  ZBM.ZARBR 089/32000-545                    24-02-03 12.07


I mirror a server installation using rsync 2.5.6 (on both sides) with these
   -a -x --numeric-ids -H --delete --stats -e ssh -z --exclude-from ...

This happens every night. In about 80% of the cases rsync returns exit
status 12 when trying to transfer a certain file. In the other 20% the file
is transferred successfully.

Using option -vvv I found these two situations:

Situation 1:
built hash table
hash search b=16384 len=224018876
match at 3293185 last_match=3276800 j=201 len=16384 n=16385
match at 3325953 last_match=3309569 j=203 len=16384 n=16384
match at 3358721 last_match=3342337 j=205 len=16384 n=16384
match at 3391489 last_match=3375105 j=207 len=16384 n=16384
match at 3424257 last_match=3407873 j=209 len=16384 n=16384
match at 3457025 last_match=3440641 j=211 len=16384 n=16384
match at 3489793 last_match=3473409 j=213 len=16384 n=16384
match at 3522561 last_match=3506177 j=215 len=16384 n=16384
match at 3555329 last_match=3538945 j=217 len=16384 n=16384
Read from remote host Gaserv02.zeppelin.corp: Connection reset by peer
rsync: writefd_unbuffered failed to write 9 bytes: phase "unknown": Broken
rsync error: error in rsync protocol data stream (code 12) at io.c(515)
_exit_cleanup(code=12, file=io.c, line=515): about to call exit(12)

Situation 2:
match at 47939585 last_match=47939585 j=2926 len=16384 n=0
match at 47955969 last_match=47955969 j=2927 len=16384 n=0
match at 47972353 last_match=47972353 j=2928 len=16384 n=0
match at 47988737 last_match=47988737 j=2929 len=16384 n=0
match at 48005121 last_match=48005121 j=2930 len=16384 n=0
match at 48021505 last_match=48021505 j=2931 len=16384 n=0
match at 48037889 last_match=48037889 j=2932 len=16384 n=0
deflate on token returned 0 (16384 bytes left)
rsync error: error in rsync protocol data stream (code 12) at token.c(288)
_exit_cleanup(code=12, file=token.c, line=288): about to call exit(12)

The file in question is a rather "ugly" one as it is rather big (220 MB)
and as it is a file where it is likely that modifications are scattered
almost randomly throughout the file. So I guess that rsync has a lot of
work with it (> 13000 matches if transferred successfully).

When I look through the logs it caught my eye that the file which was
transferred before was the first in this process which had "false alarms".
On the other hand, the same happens in those cases when the transfer
suceeds, so I am afraid this observation is of no use.

Does anyone has an idea what is going on here and how to avoid it?
I even thought about an instability in the NIC driver on high network
traffic but stressing the driver by an scp or so reveals no such problems.

As this is the only file which has these problems and as I know that this
file changes daily my workaround is to transfer it using scp beforehand, so
rsync recognizes it to be already up to date. But this of course will break
should more files start to show that behaviour. Please let me know if more
information is needed.

Regards ... Christian

Christian Reiber, Zeppelin Baumaschinen GmbH, IT/System Engineering
eMail: Christian.Reiber at zeppelin.com

---- 24-02-03 12.07 ---- Gesendet an   ------------------------------------

More information about the rsync mailing list