David Birnbaum davidb at
Wed Feb 13 06:28:49 EST 2002

On Tue, 12 Feb 2002, Dave Dykstra wrote:

> > Well, I decided to burn some disk space and did a truss of the whole
> > thing...and caught it in the act.  It looks as though the first process
> > gets an EPIPE.  If memory serves, EPIPE should only occur when the child
> > has died on the other side!  Which also gets an EPIPE, amazingly enough.
> Not exactly -- an EPIPE/SIGPIPE comes from trying to write to a pipe which
> has no reader.  It's not necessarily a child.

Yes, the thing on the other end.  Which, as you saw, can come from a TCP
connection (when the thing on the other end dies).  However, I've never
seen a connection "die" on both ends at the same time, where they both get
the EPIPE.

> Yes, it would be helpful to know which side gets the EPIPE first.  Use the
> truss -d option to add a timestamp.  That makes a timestamp relative to the
> start of the trace on each side so they'll be a little off from each other
> but if you start them both about the same time that should tell us which
> one was first.

Truss underway...results shortly.

> It appears that the TCP connection is getting torn down first.  Next time
> you post watch the netstat output on both sides to see what's happening
> with the TCP queues for that connection just before it dies, especially if
> it freezes for a while before dying.

It does seem that both sides are hanging for a significant amount of time;
not sure what is going on at that point, but there's no system calls.

> Also tell us the complete command line of the rsync command you're
> using.  Although it may seem unlikely, a Solaris bug is a possibility
> because rsync greatly stresses TCP implementations and has exposed
> many TCP bugs in the past.  What version of Solaris is running on each
> side, and are they up to date on their patches? If netstat shows data
> in a send queue that is not being sent, that points to a TCP problem.

We have the latest patches of Solaris 2.8; at least, within a month or so.

Thanks for the help thus far, hopefully the next batch of truss's will
shed more light on the situation.


More information about the rsync mailing list