[gentoo-user] Upgrade to rsync-3.2.0-r1 results in "didn't get server startup line"

2020-06-30 Thread Steve Freeman
I have a local gentoo repo mirror that has been running well for years.  
It is essentially the same setup as described at 
https://wiki.gentoo.org/wiki/Local_Mirror except that it runs on a 
non-default port.


After upgrading to net-misc/rsync-3.2.0-r1 (from rsync-3.1.3), I can no 
longer emerge --sync from my clients.  I receive messages such as:


# emerge --sync
>>> Syncing repository 'gentoo' into '/var/db/repos/gentoo'...
>>> Starting rsync with rsync://10.10.10.10:5873/gentoo-portage...
>>> Checking server timestamp ...
opening tcp connection to 10.10.10.10 port 5873
Connected to 10.10.10.10
msg checking charset: UTF-8
	sending daemon args: --server --sender -lWtprze.iLsfxCIv 
--timeout=180 --safe-links --inplace . 
gentoo-portage/metadata/timestamp.chk  (8 args)


rsync: didn't get server startup line
[Receiver] _exit_cleanup(code=5, file=main.c, line=1777): entered
	rsync error: error starting client-server protocol (code 5) at 
main.c(1777) [Receiver=3.2.0]
	[Receiver] _exit_cleanup(code=5, file=main.c, line=1777): about to call 
exit(5)



The rsyncd server shows a successful connection in the logs, and it even 
logs "rsync allowed access on module gentoo-portage".


I've tried turning up the verbosity on both the server and client, but 
it doesn't really change much.


Googlies such as "rsync didn't get server startup line" have turned up 
nothing useful at all.


The rsync 3.2.0 changelog didn't help me either ( 
https://download.samba.org/pub/rsync/NEWS#3.2.0 ), but I suspect there 
must be a clue here.


If I roll the server version back to rsync-3.1.3, it performs normally.  
Upgrading the server again to rsync-3.2.0-r1 causes it to break again.  
Client version appears to be irrelevant.


Running rsync as a non-daemon appears to work fine regardless of 
server/client versions; it's only rsyncd that fails.


With no useful logs or output, I'm finding this impossible to diagnose.  
Does anyone have any ideas?


Thanks,

Steve Freeman




Re: [gentoo-user] Upgrade to rsync-3.2.0-r1 results in "didn't get server startup line"

2020-07-01 Thread Wynn Wolf Arbor
Hi Steve,

On 2020-06-30 20:35, Steve Freeman wrote:
> I have a local gentoo repo mirror that has been running well for
> years.  It is essentially the same setup as described at
> https://wiki.gentoo.org/wiki/Local_Mirror except that it runs on a
> non-default port.

I sadly cannot reproduce this on my systems with a similar setup. Could
you attach the full rsyncd.conf file? Perhaps there's also custom
settings in /etc/conf.d/rsyncd.

> rsync: didn't get server startup line
> [Receiver] _exit_cleanup(code=5, file=main.c, line=1777): entered
> rsync error: error starting client-server protocol (code 5) at main.c(1777) 
> [Receiver=3.2.0]
> [Receiver] _exit_cleanup(code=5, file=main.c, line=1777): about to call 
> exit(5)

I've had a look in the code, and that particular message is only
triggered in one place:

if (!read_line_old(f_in, line, sizeof line, 0)) {
rprintf(FERROR, "rsync: didn't get server startup line\n");
return -1;
}

read_line_old is described thusly:

/* Read a line of up to bufsiz-1 characters into buf.  Strips
 * the (required) trailing newline and all carriage returns.
 * Returns 1 for success; 0 for I/O error or truncation. */
int read_line_old(int fd, char *buf, size_t bufsiz, int eof_ok)

> Running rsync as a non-daemon appears to work fine regardless of
> server/client versions; it's only rsyncd that fails.
>
> With no useful logs or output, I'm finding this impossible to
> diagnose.  Does anyone have any ideas?

I have no concrete ideas, but given that read_line_old seems to fail,
maybe it's helpful checking out actual network traffic with wireshark or
tcpdump. You could compare traffic between the working and the broken
version. A simple capture filter of 'port 5873' should be enough.

Since there really doesn't seem to be any better debug functionality
(there's --debug, but it didn't really add anything for me), perhaps you
could also build rsync with debug symbols and throw gdb at it.

Finally, have you tried accessing the rsync endpoint manually without
invoking 'emerge --sync'? Does the following also raise an error?

rsync --port 5873 10.10.10.10::

If not, perhaps try syncing a single file manually.

I also see that version 3.2.1 is in the tree now, could be worth a shot
too.

-- 
Wolf