rsync error: error in rsync protocol data stream (Broken pipe)

[jw schultz]

On Wed, Jun 18, 2003 at 10:38:54AM -0400, Andrew J. Schorr wrote:
> On Tue, Jun 17, 2003 at 06:35:50AM -0700, jw schultz wrote:
> > 
> > You could try turning on transfer logging i suppose.  If you
> > haven't already done so you might want to use the "log file"
> > option in case chroot is getting in the way.  Beyond this i
> > have no suggestions; i dont use rsyncd.
> 
> I may be having a similar problem.  I'm using rsync version 2.5.6cvs-20030205
> every night on Solaris 8/x86 to do a backup from a client system to a 
> backup server using rsyncd.  Almost every night I see the following errors
> logged on the rsyncd server:
> 
> Jun 18 00:48:18 ead62 rsyncd[9632]: [ID 702911 daemon.warning] inflate returned -3 (0 bytes)
> Jun 18 00:48:18 ead62 rsyncd[9632]: [ID 702911 daemon.warning] rsync error: error in rsync protocol data stream (code 12) at ../token.c(416)
> Jun 18 00:48:18 ead62 rsyncd[9632]: [ID 702911 daemon.warning] rsync: connection unexpectedly closed (197041 bytes read so far)
> Jun 18 00:48:18 ead62 rsyncd[9632]: [ID 702911 daemon.warning] rsync error: error in rsync protocol data stream (code 12) at ../io.c(187)
> 
> And on the client side, I see the following error:
> 
> rsync: writefd_unbuffered failed to write 42 bytes: phase "unknown": Broken pipe
> rsync error: error in rsync protocol data stream (code 12) at ../io.c(622)
> 
> This has been happening to me for months almost every night.  I find
> that I can check the return code from rsync to see whether the
> transfer succeeded.  If it failed, I simply try again, and it almost
> always finishes the backup successfully on the second invocation.  But if
> not I keep retrying up to 10 times.  I think one evening it took 9 attempts,
> but most of the time it works in 2 tries.  It's a hack, but it gets
> the job done, and I was having no luck debugging the problem.

"inflate returned -3" is a compression error where it has
bad data.  It could be there is a bug in zlib but it seems
more likely there is something wrong on your systems,
perhaps flaky hardware.  I haven't looked into that part of
the code much, it is possible this could be a symptom of a
file being changed during the transfer.

If this is happening that frequently i'd try not using the
-z option.

-- 
________________________________________________________________
	J.W. Schultz            Pegasystems Technologies
	email address:		jw at pegasys.ws

		Remember Cernan and Schmitt