<...snip...> > Does this tell anyone anything? If not, I could traverse the learning > curve on getting gdb information from the process.
As a point of information, when rsync is run, as in this case using ssh, it is using ssh to start a remote rsync on the server. These two rsyncs are able to communicate with each other because the standard in (stdin) of each is connected to the standard out (stdout) of the other over the network. So althought there is buffering, each must read and write at the appropriate times in a well understood sequence/protocol as other wise they come out of sync and fail, most likely in a deadlock. On the surface is *looks* like the problem is that the local rsync is hanging on a write to stdout (descriptor 1 in your trace). The question is why. It is not clear to me if it has simply failed to fully read all that the remote rsync needs to send and therefore there is in a deadly embrace or the remote has exited and the socket wasn't properly cleaned up. As far as using gdb, rather than using the full rsync command line, use the command 'gdb rsync' to start rsync in the debugger. Then enter the command 'run balance-of-rsync-command-line' and it should run normally. Once it hangs, use control-c to break to the gdb command prompt and use the command 'where' or 'bt' (back trace) to print a stack trace. It would be very interested to log into the server and use ps to locate the remote rsync during the run. I don't know of this is an option for you. If so, you could see if the remote rsync has exited. If not, you could attach to it using gdb and perform a stack trace, presuming you could compile it with debug. Kinda of a pain as you'd have to either move it to /usr/bin or you could explicitly reference the alternate copy in your Cygwin built rsync. That is the local rsync will build a command line to run rsync on the server via ssh that depends on the path, but you could hard-code a path to your debuggable rsync on the server. Not sure how far you want to push this, I think this is going to take some digging. Brett ---------------------------------------------------------------- Brett C. Serkez, Techie -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/