rsync server: /usr/local/bin/rsync --address=194.109.216.71 --numeric-ids --no-detach --daemon --config=rsyncd.conf rsyncd.conf: pid file = /var/run/rsyncd.pid uid = rsync gid = rsync use chroot = yes max connections = 10 [freebsd-ports] comment = FreeBSD ports repository path = /home/mirror/freebsd/rsync/ports client commandline: rsync -avvP cvsup.gay.nl::freebsd-ports/ /usr/ports/ client output: opening tcp connection to cvsup.gay.nl port 873 receiving file list ... [receiver] expand file_list to 131072 bytes, did move [receiver] expand file_list to 262144 bytes, did move [receiver] expand file_list to 524288 bytes, did move 84165 files to consider after this, nothing. strace on both server and client shows select(), waiting (according to sockstat) on the socket to the other party. Workaround: remove --numeric-ids from the server startup line. Extra details: - no combination of enabling or disabling chroot and no-detach made any difference - with chroot but no numeric-ids, the following syslog message occurs: Oct 10 01:22:45 s1 rsyncd[25003]: /etc/pwd.db: No such file or directory but everything works fine It seems some conditional somewhere goes horribly wrong; no combination of flags should ever cause server and client to be waiting for eachother.
The problem is that the --numeric-ids option is a client option, not a server option, so setting it on the server side creates confusion in what the client is going to send over the wire. The proper solution is to separate the parsing of daemon mode from normal rsync mode so that client options cannot be specified when starting a daemon, and also so that daemon options cannot be specified when starting a client.
Created attachment 717 [details] Change option parsing This patch separates the daemon-mode's option parsing from the normal client/server's option parsing. It also separates the options in the usage message (requiring the user to use "rsync --daemon --help" to see the daemon options). Lightly tested, including daemon mode over ssh. Need to double-check option parsing separation to ensure I didn't miss anything.
I checked in a slightly modified version of the attached patch that will no longer allow a daemon to be started with non-daemon options specified.