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. David.
