Description of Problem: Using the following command rsync 2.5.3 from skipjack2 fails during the transfer of files from kernel.org: rsync -rltv --partial --delete --delete-excluded" \ rsync://rsync.kernel.org/pub/linux/kernel/ \ /var/ftp/pub/mirrors/kernel.org/ Version-Release number of selected component (if applicable): 2.5.4-1 skipjack2 How Reproducible: 100%. The amount transfered before a failure tends to change. Steps to Reproduce: 1. Use the above command. It may require a full kernel.org mirror initially existing since it could be a result of dealing with huge file lists? Actual Results: Sample errors I see after the transfer times out: rsync: connection unexpectedly closed (1493971 bytes read so far) rsync error: error in rsync protocol data stream (code 12) at io.c(151) rsync: error writing 4092 unbuffered bytes - exiting: Broken pipe rsync error: error in rsync protocol data stream (code 12) at io.c(464) or rsync: connection unexpectedly closed (1502394 bytes read so far) rsync error: error in rsync protocol data stream (code 12) at io.c(151) rsync: connection unexpectedly closed (1502374 bytes read so far) rsync error: error in rsync protocol data stream (code 12) at io.c(151) or rsync: connection unexpectedly closed (1506952 bytes read so far) rsync error: error in rsync protocol data stream (code 12) at io.c(151) rsync: connection unexpectedly closed (1504880 bytes read so far) rsync error: error in rsync protocol data stream (code 12) at io.c(151) Additional Information: Saddly I see the same problem with 2.5.5 when built from tgz source. The kernel.org mirror pages state that a older version (2.4.x?) is recomended due to problems with the current stable series. This may be a compatablity bug between 2.5.[45] and older 2.4.x versions?
Confirmed from hpa that rsync.kernel.org is running rsyncd 2.4.6 with security patches.
*all* security patches?
yeah, I know. Okay, he didn't say 'all'. But that's the answer I got. Here's the answer cut'n'paste from the email: >> 2.4.6 with security patches. >> >> -hpa What it means is anyones guess. I assume zlib patches. Beyond that I'm not sure what patches are added to the 2.4.6 source kernel.org uses vs a stock tgz source.
New discovery today which may make this bug report a false alarm, or not what it seems at the very least. Old Environment: IBM used to have a socks5 server between it's Intranet and the Internet. Previously when I reported this problem I was using socks5 conections from tsocks 1.7 to make connections from our internal site to the rsync.kernel.org system. New Environment: Today IBM enabled PIX and eliminated the socks5 servers in the process. I removed the export LD_PRELOAD=/lib/libtsocks.so line from my rsync scripts as a result. This disables use of the tsocks 1.7 socks5 libs. After making the above change I can now sync with kernel.org using rsync 2.5.4 and 2.5.5. I've confirmed this with multiple syncs against various amounts of data and all of them complete. Based on this my current conclusion is that the problems reported were either the result of: a) rsync 2.5.4 + IBM socks5 server problems that don't show up under 2.4.6 b) rsync 2.5.4 + tsocks 1.7 problems that don't shwo up with rsync 2.4.6. I doubt there's a compatability problem between rsync 2.5.4 and 2.4.6 as I first reported. For reference the IBM socks5 servers use the commercial Aventail socks5 product running on AIX. Since the socks servers have been moved out of the loop and tsocks disabled I'm no longer able to reproduce the reported errors. As for this bug report, I'll leave it up to you guys to decide if it should be closed or not. :) Thanks for the help.
OK, closing as notabug (i.e., notourbug ;) )