rsync over ssh hang issue understood *Revisited*

Jonathan Hurd
Fri Sep 7 14:57:00 GMT 2007

Sorry to bring back this old thread back. Is there anyone that can 
explain a fix for this problem. I've only been using rsync/cygwin/on ssh 
for about 3 weeks, so please explain in dummy terms.

It's the exact same problem mentioned here:
----- Original Message ----- From: "René Berber"
Steven Hartland wrote:
Just to back this up, we cant get basic rsync to run reliably
using cygwin either. The command being tested is run from a
FreeBSD box with the source being a cygwin box using cygwin
rsync -av cygwin1:/testdir/ /testdir/

The result is it will randomly hang on a file, no output / error
returned just stops.

tcsh                    6.14.00-5          OK

While testing is csh involved?

Your description above is very close to a problem with cvs reported and 
recently by Jay Abel.  In short, tcsh at the receiving end is changing 
\r\n to
\n inside binary files, so the receiving process waits for the expected 
but it receives less.

tcsh is the default shell on FreeBSD which is the "recieving"
end in this test yes but I'm a little confused how the shell
could effect the results of rsync? FreeBSD to FreeBSD for FreeBSD
to Windows SFU doesnt have this issue so something specific to
tcsh on cygwin?

An example of this failure is:
rsync -av --progress cygwin1:/testdir/ /testdir/
receiving file list ...
1705 files to consider
created directory testdir
           0   0%    0.00kB/s    0:00:00
***Hung here***
^CKilled by signal 2.0.00kB/s    0:00:00
rsync error: received SIGINT, SIGTERM, or SIGHUP (code 20) at 
rsync.c(242) [receiver]
rsync error: unexplained error (code 255) at rsync.c(242) [generator]

Brett Serkez wrote:
> After running into the hang trying to use rsync over ssh on Cygwin,
> reported on this mailing list, but with no resolution other than use of
> daemon mode, I tracked down the problem.  I have rsync working over ssh
> on Cygwin.
> The hang is occuring when rsync is attempting to exchange protocol
> version numbers, it writes its version and then hangs waiting endlessly
> for a reply.  The ssh process is detached, and apparently not diretly
> connected to rsync, as it is an orphan, owned by process 1.  The ssh
> process never even gets as far as attempting network access and rsync
> never does anything of value.
> Not defining HAVE_SOCKETPAIR in the make configuration is enough to use
> pipe() vs. socketpair(), which is enough for rsync to run using ssh,
> just as it does on UNIX.  While I've not done extensive testing, I've
> used it enough to believe it is working as designed/intended.
> The source file that is effected by the above change (primarily) is
> util.c in function: fd_pair():
> 	ret = socketpair(AF_UNIX, SOCK_STREAM, 0, fd);
> #else
> 	ret = pipe(fd);
> #endif
> While use of socketpair() may be a better method, use of pipe() does
> work and I'd request that the rsync package maintainer please rebuild
> the package with this build option change and reissue the package so all
> can benefit.  Perhaps socketpair() can be used with a future release of
> Cygwin?
> Thank you,
> Brett
> ----------------------------------------------------------------
> Brett C. Serkez, Techie

Unsubscribe info:
Problem reports:

More information about the Cygwin mailing list