Bug 55245 – distfile rsync with primary mirror fails (rsync issue)

• Product: Mirrors
• Status: RESOLVED FIXED

[Description Sebastian Werner 2004-06-26 09:04:59 UTC]

first: no, this is _not_ a duplicate to #49933, its related.

ftp.uni-erlangen.de (running SuSE Linux) still got massive problems syncing with its designated upstream mirror ftp.oregonstate.edu. the upstream server has (according to nmap -sV) protocol version 28.

we tried to rsync using rsync versions:
- 2.5.7
- 2.6.0
- 2.6.1
- 2.6.2
all built from scratch using just plain configure.
capabilities of all versions are:
64-bit files, socketpairs, hard links, symlinks, batchfiles, IPv6, 64-bit system inums, 64-bit internal inums 

commandline used was:
--partial --stats --progress --verbose --recursive --links --times --delete --password-file=gentoo.passwd [e-mail]::gentoo .mirrors/gentoo

output was:
a) 2.5.7
rsync: read error: Connection reset by peer
rsync error: error in rsync protocol data stream (code 12) at io.c(177)
b) 2.6.0
rsync: read error: Connection reset by peer
rsync error: error in rsync protocol data stream (code 12) at io.c(201)
c) 2.6.1
rsync: read error: Connection reset by peer
rsync error: error in rsync protocol data stream (code 12) at io.c(354)
d) 2.6.2
rsync: read error: Connection reset by peer
rsync error: error in rsync protocol data stream (code 12) at io.c(354)

somebody said, that ipv6 might be the issue, so I rebuild (after make distclean) also every version mentioned above with --disable-ipv6.
but there was no change in result.

right now, we are syncing with ibiblio.org cause they still run a server with protocol version 26, which works without _any_ problems with any of the versions mentioned above.

i also got a sample strace running 2.6.0 without v6 support(just the interesting part):

18:00:59.622236 socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 3
18:00:59.622297 connect(3, {sa_family=AF_INET, sin_port=htons(873), sin_addr=inet_addr("128.193.0.3")}, 16) = 0
18:00:59.803633 select(4, NULL, [3], NULL, {60, 0}) = 1 (out [3], left {60, 0})
18:00:59.803874 write(3, "@RSYNCD: 27\n", 12) = 12
18:00:59.803932 select(4, [3], NULL, NULL, {60, 0}) = 1 (in [3], left {54, 813000})
18:01:04.991021 read(3, 0xbfffd490, 1)  = -1 ECONNRESET (Connection reset by peer)
18:01:04.991118 write(2, "rsync: read error: Connection re"..., 44rsync: read error: Connection reset by peer
) = 44
18:01:04.991181 rt_sigaction(SIGUSR1, {SIG_IGN}, {0x8051520, [USR1], SA_RESTORER|SA_RESTART, 0x40063aa8}, 8) = 0
18:01:04.991246 rt_sigaction(SIGUSR2, {SIG_IGN}, {0x8051540, [USR2], SA_RESTORER|SA_RESTART, 0x40063aa8}, 8) = 0
18:01:04.991379 write(2, "rsync error: error in rsync prot"..., 72rsync error: error in rsync protocol data stream (code 12) at io.c(201)
) = 72
18:01:04.991468 exit_group(12)          = ?

[Comment 1 Kurt Lieber (RETIRED) 2004-09-11 04:49:44 UTC]

we recently moved the master distfiles mirror to a new server (masterdistfiles.gentoo.org -- user/password are the same as with ftp.oregonstate.edu)  Are you still seeing the same problem?

[Comment 2 Sebastian Werner 2004-09-11 05:36:07 UTC]

this bug solved itself when the new primary mirror was introduced.
thanks anyway.