(In reply to comment #0)
> The fileset (file list) is large and it seems the rsync is hung
> somewhere with write error
I'm assuming by "hung" you mean more of a "hang up", as in problem-causing item where rsync died, rather than "hung" as in the process keeps running but stops doing anything useful.
The truss output shows 2 processes on the server side which discover that the remote connection has closed, so there's nothing going wrong with rsync. If the client side is seeing a similar error, this just means that the network connection failed and both sides noticed it.

>I'm assuming by "hung" you mean more of a "hang up", as in problem-causing item
>where rsync died, rather than "hung" as in the process keeps running but stops
>doing anything useful.
It's more of the latter. The rsync from the sender did not die immediately while the receiver (the host which generated the truss output) had already closed the connection. The sender stayed alive but doing nothing until it reached the timeout (3600). Btw, the sender and receiver is linked by WAN.. so maybe it's the WAN link which drops the link? I'll check.. thanks.

(In reply to comment #3)
We had the MIS turned off the hardware compression unit for the US-UK link and the problem went away. Turned it back on and it failed again. So it's probably the WAN quality and probably has nothing to do with rsync itself.
> It's more of the latter. The rsync from the sender did not die immediately
> while the receiver (the host which generated the truss output) had already
> closed the connection. The sender stayed alive but doing nothing until it
> reached the timeout (3600). Btw, the sender and receiver is linked by WAN.. so
> maybe it's the WAN link which drops the link? I'll check.. thanks.