The Samba-Bugzilla – Bug 1900
rsync --daemon hangs with --numeric-ids
Last modified: 2005-04-01 11:21:16 UTC
/usr/local/bin/rsync --address=188.8.131.52 --numeric-ids --no-detach --daemon
pid file = /var/run/rsyncd.pid
uid = rsync
gid = rsync
use chroot = yes
max connections = 10
comment = FreeBSD ports repository
path = /home/mirror/freebsd/rsync/ports
rsync -avvP cvsup.gay.nl::freebsd-ports/ /usr/ports/
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.
- 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: /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
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.