SIGUSR1 or SIGINT error
David Birnbaum
davidb at chelsea.net
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.
David.
More information about the rsync
mailing list