In the two times that I've synced with rsync server pan.ubishops.ca, it has been 10-11 hours out of date (rather than having the latest 30-minute update). The two times I synced with it were tonight (July 25th at around 10:10pm PDT) and about 45 hours prior to that.
I admin pan.ubishops.ca, and I checked the logs and pan is updating every 30 minutes, but it's been failing lately. I get (code 12) at io.c (165). It's an error in the rsync protocol data stream. I've tried re-compiling rsync and I've also tried using the latest cvs. Unless anyone knows a fix for this, I'm afraid that the mirror-admin will have to remove me from the rotation.
(Note: I'm one of the rsync maintainers.) Thomas: In rsync 2.5.6, the error you cite (at io.c line 165) is an EOF error caused by one of the read_timeout() calls returning 0 bytes. That most likely means an EOF on the socket to the sender, but it could also be an EOF on the pipe/socketpair to the generator process (which is also on the receiving side). It would help in the diagnosis of the rsync problem if you could get the admin for whatever site you connect with to look for errors in the rsync-daemon log (which I assume is how the mirrors run -- you don't use an ssh connection, do you?). You can also use the rsync mailing as a resource if you'd care to talk about the error there: rsync@lists.samba.org .
Just did a spot check to make sure, and its still out of sink. Removed from the .ca and .namerica rotations. Still active as rsync3.ca. Also, could we get the motd file to indicate that it is rsync3.ca.gentoo.org? Thanks.
> motd file to indicate that it is rsync3.ca.gentoo.org done. I haven't been able to resolve the rsync error. The error doesn't always happen. Sometimes it works, and sometimes it doesn't. Anyway, I have an extra box, so I'll do a fresh install and setup rsync on it. Then I'll swap it with pan.ubishops.ca. It'll have the same ip address. I'll let you know when the new box is in place. It should be later tonight.
I setup another box (running OpenBSD w/rsync-2.5.5 from ports) and I still get this error: Started update at Tue Jul 29 20:03:06 EDT 2003 receiving file list ... done rsync: connection unexpectedly closed (1232960 bytes read so far) rsync error: error in rsync protocol data stream (code 12) at /usr/ports/net/rsync/w-rsync-2.5.5/rsync-2.5.5/io.c(150) rsync: connection unexpectedly closed (1232960 bytes read so far) rsync error: error in rsync protocol data stream (code 12) at /usr/ports/net/rsync/w-rsync-2.5.5/rsync-2.5.5/io.c(150) End: Tue Jul 29 20:07:13 EDT 2003 I've tried everything I can thing of. I've tried a different network cable plugged into a different wall jack. It should work. We have another rsync mirror on the same network (rsync1.ca.gentoo.org - 206.167.194.132) and that works just fine. Anyone got any hints? Here's my rsync script: #!/bin/sh RSYNC="/usr/local/bin/rsync" OPTS="--verbose --recursive --links --perms --times --devices --delete --timeout=900"rsync1.us.gentoo.org SRC="rsync://rsync1.us.gentoo.org/gentoo-portage" DST="/home/gentoo/" echo "Started update at" `date` >> $0.log 2>&1 logger -t rsync "re-rsyncing the gentoo-portage tree" ${RSYNC} ${OPTS} ${SRC} ${DST} >> $0.log 2>&1 echo "End: "`date` >> $0.log 2>&1
jw schultz <jw@pegasys.ws> from the rsync mailing list says this about my error: "It means the connection was unexpectedly closed. This message is often preceded with a message telling why the other end of the connection closed it. If not, you will need to look to the other end for info." There was no preceding message telling me why the other end of the connection closed it. Can someone at the other end check?
I'm not that familiar with rsync, but there are some errors in the log. I'm assuming its our end of your errors: rsync on gentoo-portage from PAN.ubishops.ca (206.167.194.175) readlink metadata/timestamp.chk: No such file or directory wrote 1262610 bytes read 1329 bytes total size 43394131 rsync error: some files could not be transferred (code 23) at main.c(383) and rsync on gentoo-portage from PAN.ubishops.ca (206.167.194.175) rsync error: timeout in data send/receive (code 30) at io.c(103) Someone that knows more than I will need to look at it. In the meantime, if you could sync this box with rsync1.ca, that might tell us something.
> if you could sync this box with rsync1.ca, that might tell us something. done. I've rsynced with rsync1.ca 4 times so far and I haven't gotten an error. I'll continue to rsync from rsync1.ca on :00 and :30 and watch for errors.
I assume that the OPTS line in comment #5 is a typo, since it would result in the timeout value having a string appended to it (which popt would reject with a fatal error): --timeout=900rsync1.us.gentoo.org I'd suggest trying to sync with the original server with a higher timeout value and see if that makes the EOF errors go away -- if so, that would at least let us know that the only problem was slowness in the dialog between the two servers and not some other bugginess.
> I assume that the OPTS line in comment #5 is a typo Sorry I didn't cut and paste it correctly. OPTS="--quiet --recursive --links --perms --times --devices --delete --timeout=9999" Even with --timeout=9999 I get this: Started update at Wed Jul 30 13:30:01 EDT 2003 rsync: connection unexpectedly closed (1233552 bytes read so far) rsync error: error in rsync protocol data stream (code 12) at /usr/ports/net/rsync/w-rsync-2.5.5/rsync-2.5.5/io.c(150) rsync: connection unexpectedly closed (1233552 bytes read so far) rsync error: error in rsync protocol data stream (code 12) at /usr/ports/net/rsync/w-rsync-2.5.5/rsync-2.5.5/io.c(150) End: Wed Jul 30 13:34:38 EDT 2003
A couple of thoughts: a) there's no way -z or --compress is sneaking in, is there? b) what about ECN? It's not enabled on rsync1.us., but what about at pan's end? c) How about a more sane timeout, e.g. leaving it at the default 120? (If you're going to have a problem, better that you know about it sooner rather than having multiple cron-jobs overlapping because they're all waiting 9999s.) d) the options I'm using here are -rlptDz --delete (interesting, I have -z and no problems??) if it helps.
> a) there's no way -z or --compress is sneaking in, is there? not that I know of > b) what about ECN? I know what ECN is, but how do I tell if it's enabled? > c) How about a more sane timeout, e.g. leaving it at the default 120? I've tried 120, 300 (http://bugs.gentoo.org/show_bug.cgi?id=20510#c5), 900 and >900 (http://bugs.gentoo.org/show_bug.cgi?id=25301#c9) > d) the options I'm using here are -rlptDz --delete I still get the same error when I try your options
The problem is most likely that rsync1.us is being overloaded and preventing some mirrors from syncing properly. I'm going to monitor the server again to see if the problem continues. If it does we'll put this on hold until we can fix the problem.
I still get this: Started update at Wed Sep 10 09:00:01 EDT 2003 rsync: connection unexpectedly closed (1366002 bytes read so far) rsync error: error in rsync protocol data stream (code 12) at io.c(165) rsync: connection unexpectedly closed (1366002 bytes read so far) rsync error: error in rsync protocol data stream (code 12) at io.c(165) End: Wed Sep 10 09:04:30 EDT 2003
OK, looks like we'll have to wait and see what happens after we take some of rsync1.us' workload. Will post back when we've made progress.
We've resolved the problem with rsync1.us. Are you still interested in offering the mirror (I noticed it doesn't appear to be responding).
I am no longer interested in being an rsync mirror.
OK, Thanks for your time.