On Sun, Sep 07, 2003 at 11:32:24PM -0400, Jim Salter wrote:
> > What you describe is that the sender is dying but you don't
> > get a message from it as to why. Start by looking in the
> > rsyncd log file. If that doesn't yield an informative
> > message try pushing the transfer (run it on the other system
> > with the args switched) then you should see an error
> > message.
>
> Sep 7 21:20:09 ph34r rsyncd[37881]: rsync: writefd_unbuffered failed to
> write 4096 bytes: phase "unknown": Broken pipe
> Sep 7 21:20:09 ph34r rsyncd[37881]: rsync error: error in rsync protocol
> data stream (code 12) at io.c(515)
> Sep 7 21:21:08 ph34r rsyncd[37882]: rsync: writefd_unbuffered failed to
> write 4096 bytes: phase "unknown": Broken pipe
> Sep 7 21:21:08 ph34r rsyncd[37882]: rsync error: error in rsync protocol
> data stream (code 12) at io.c(515)
> Sep 7 21:36:30 ph34r rsyncd[37883]: rsync: writefd_unbuffered failed to
> write 4096 bytes: phase "unknown": Broken pipe
> Sep 7 21:36:30 ph34r rsyncd[37883]: rsync error: error in rsync protocol
> data stream (code 12) at io.c(515)
>
> That's what comes from grepping /var/log/messages for rsync on the machine
> running the rsync daemon. It looks like it's harfing several times before
> finally dying irrevocably. Does it help you any? It leaves me just as
> mystified as I was before.
Not really. Those are in pairs. I'm not looking at the
source so this is off the top of my head: It tries to write,
fails then it fails trying to send the error message to the
client before exit.
Something is closing the session between the client and
server. The last time this was happening it was a firewall.
This could also be caused by an error in the TCP protocol
stack.
> ... but I got suspicious and changed out the NIC on the client machine.
Are you saying that fixed it? A bad NIC should be producing
tons of messages from the TCP stack.
> Yup - it works fine all day long for "normal use", but if you ask it to
> squeeze several gigs of data through it without ever once resetting the
> connection, it harfs and dies. Not really an rsync problem at all, except
> in that rsync is apparently FAR less tolerant of network problems than ftp
> or smbclient.
ftp retries if a session gets dropped. Samba was made to
tolerate session failure so it retries. Rsync takes the TCP
spec at its word as a reliable protocol that delivers
packets in order or fails outright. Something is causing
the session to fail. If it is the TCP stack there should be
something messages bad nic or good.
--
________________________________________________________________
J.W. Schultz Pegasystems Technologies
email address: [EMAIL PROTECTED]
Remember Cernan and Schmitt
--
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
