I have been trying to get rsync running correctly on cygwin for the past couple of days. I found a post on the cygwin list that said there was a bug in cygwin when using socketpair() but when I compiled the sample code: (http://jrepp.com/rsync/socketpair.c) both ways it works fine. Here's the article for reference: http://sources.redhat.com/ml/cygwin/2001-08/msg00357.html I am running the latest update from cvs Here's what happens when I try to get a module list from the cgywin system from a freebsd4.4 system: http://jrepp.com/rsync/packetlog.txt fisher "Fisher Replicated Directory" rsync: read error: Connection reset by peer rsync error: error in rsync protocol data stream (code 12) at io.c(151) read_timeout is calling die_from_error with errno == 104 when going from cygwin to cygwin (uname: CYGWIN_NT-5.0 IGXDEV21 1.3.3(0.46/3/2) 2001-09-12 23:54 i686 unknown) I get just: rsync: read error: Connection reset by peer rsync error: error in rsync protocol data stream (code 12) at io.c(151) I have tried compiling with and without -DSOCKET_PAIR with the same results. On a side note here is a simple patch to help when running rsync as a service, this patch doesn't fix or cause the error (the error exists before this patch) Index: socket.c ==================================================================RCS file: /cvsroot/rsync/socket.c,v retrieving revision 1.36 diff -r1.36 socket.c 443a444,452> #ifndef __CYGWIN__ > /* jrepp: This causes problems when using rsync > under srvany.exe as a service, srvany loses > track of rsync.exe because it kills it's original > process. This doesn't hurt seem to hurt when running > it straight from the cmdline either. > > TODO: should this be a autoconf macro (to cover MsDev in future aswell)?> */446a456> #endif /* __CYGWIN__ */I'm going to keep trying to fix this of course but if anyone else has a quick patch or any suggestions they would be most appreciated. -jake
On Friday 19 Oct 01, Jake Repp writes:> I have been trying to get rsync running correctly on cygwin for the past > couple of days.Have you used the version of rsync that is shipped with Cygwin? Or are you trying to run it as a daemon? I don't think anyone has got that working. Would be great if you could, but that's probably a cygwin problem, not a rsync problem. Regards, David (Cygwin FAQ maintainer)
Dave: I remember a thread where it was decided to default to "use chroot = no" on systems that don't support it. Is it a pretty recent build? Am I remembering wrong? Tim Conway tim.conway@philips.com 303.682.4917 Philips Semiconductor - Longmont TC 1880 Industrial Circle, Suite D Longmont, CO 80501 Available via SameTime Connect within Philips Available as n9hmg on AIM perl -e 'print pack(nnnnnnnnnnnn, 19061,29556,8289,28271,29800,25970,8304,25970,27680,26721,25451,25970), ".\n" ' "There are some who call me.... Tim?" Dave Dykstra <dwd@bell-labs.com>@lists.samba.org on 10/22/2001 08:19:20 AM Sent by: rsync-admin@lists.samba.org To: David Starks-Browning <starksb@ebi.ac.uk> cc: rsync@lists.samba.org (bcc: Tim Conway/LMT/SC/PHILIPS) Subject: Re: rsync on cygwin: Connection reset by peer Classification: On Sat, Oct 20, 2001 at 08:32:22AM +0100, David Starks-Browning wrote:> On Friday 19 Oct 01, Jake Repp writes: > > I have been trying to get rsync running correctly on cygwin for the past > > couple of days. > > Have you used the version of rsync that is shipped with Cygwin? > > Or are you trying to run it as a daemon? I don't think anyone has got > that working. Would be great if you could, but that's probably a > cygwin problem, not a rsync problem.No, I was pretty sure that people had run the cygwin rsync in daemon mode, and since last week I got ssh access to a W2K machine running cygwin I just tried it out. It does work, at least on the simple example I used. I was surprised that I didn't even need to use "use chroot = no" because I thought people had earlier reported that that was needed. My rsyncd.conf contains only: [modulename] path = /path/to/a/directory - Dave Dykstra
Getting back to the original complaint that started this thread: On Fri, Oct 19, 2001 at 09:04:20PM -0700, Jake Repp wrote:> I have been trying to get rsync running correctly on cygwin for the past > couple of days. I found a post on the cygwin list that said there was a > bug in cygwin when using socketpair() but when I compiled the sample code: > (http://jrepp.com/rsync/socketpair.c) both ways it works fine. Here's the > article for reference: > http://sources.redhat.com/ml/cygwin/2001-08/msg00357.html > > I am running the latest update from cvs > > Here's what happens when I try to get a module list from the cgywin > system from a freebsd4.4 system: http://jrepp.com/rsync/packetlog.txt > > fisher "Fisher Replicated Directory" > rsync: read error: Connection reset by peer > rsync error: error in rsync protocol data stream (code 12) at io.c(151)I do see the same error when listing modules on an rsync --daemon running under cygwin, connecting to it from Solaris. I haven't tried to debug it though, and transfers work OK. - Dave Dykstra
This is a message I posted (one of several) awhile back that addresses at
least one rsync/winsock problem.
Randy O'Meara
I have received a few queries regarding my progress in solving the rsync
sender's abortive connection close() on Winsock-based platforms. In my
research, I stumbled across articles that implied that Microsoft is not the
only OS vendor that provides platforms that may exhibit this problem. I am
posting this response to the list in hopes that even those that sent private
and public responses to my initial postings (slamming M$ and my decision to
use this platform) may possibly reap some benefit.
The symptom, exhibited at the receiver, may be observed as "read error:
Connection Reset" (or, very close to this) when retrieving a simple module
listing from an (unpatched) rsync daemon running on a Windows 2000 or
Windows NT platform using a command such as "rsync -av daemonHost::".
In
addition, the receiver may display only a portion of the expected module
listing. Note that the problem is not exclusive to this simple module
listing mode.
The problem, as determined experimentally, lies in the manner in which the
rsync sender closes the connection (socket) that is utilized to communicate
with the receiver. The rsync protocol does not include a final phase where
both participants agree to gracefully close the connection. When the sender
completes transmission, it exits without explicitly shutting down the socket
fd. I assume that, in most *N*X-based systems, allowing the system to clean
up open file descriptors on process exit does not cause the TCP RST flag to
be set and transmitted to the remote participant. But, in at least
Winsock-based systems, the TCP RST flag is transmitted to the remote. If
the remote (regardless of platform) has not completed receiving and
processing all data packets from the sender prior to the reception of the
RST packet, the unprocessed data is discarded. An error message is
displayed and the receiver exits with a non-zero exit status.
The solution that works OK for *me* is to perform a graceful shutdown() of
socket FDs and to close() all open FDs prior to exit. I have no doubt that
a more elegant solution than the one I have implemented does indeed exist.
For this reason, I am not providing a patch-format solution. I am providing
the code that I used along with an indication of where to place the calls to
this function.
Randy O'Meara
**** place in cleanup.c just above _exit_cleanup() ****
void close_all()
/* rmo: 5/31/01
Close all open sockets and files, allowing a (somewhat) graceful
shutdown() of socket connections. This eliminates the abortive
TCP RST sent by a Winsock-based system when the close() occurs.
*/
{
int max_fd;
int fd;
int ret;
struct stat st;
max_fd = sysconf(_SC_OPEN_MAX) - 1;
for (fd = max_fd; fd >= 0; fd--) {
ret = fstat(fd,&st);
if (fstat(fd,&st) == 0){ /* Open fd */
if (is_a_socket(fd)) {
ret = shutdown(fd,2); /* Somewhat graceful */
}
ret = close(fd);
}
}
}
**** call close_all() ****
cleanup.c:_exit_cleanup() just before exit(code)
socket.c:start_accept_loop() just before _exit(ret)