Bug 1900 - rsync --daemon hangs with --numeric-ids
Summary: rsync --daemon hangs with --numeric-ids
Alias: None
Product: rsync
Classification: Unclassified
Component: core (show other bugs)
Version: 2.6.3
Hardware: All FreeBSD
: P3 normal (vote)
Target Milestone: ---
Assignee: Wayne Davison
QA Contact: Rsync QA Contact
Depends on:
Reported: 2004-10-09 17:24 UTC by Peter van Dijk
Modified: 2005-04-01 11:21 UTC (History)
0 users

See Also:

Change option parsing (6.65 KB, patch)
2004-10-11 04:01 UTC, Wayne Davison
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Peter van Dijk 2004-10-09 17:24:59 UTC
rsync server:
/usr/local/bin/rsync --address= --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

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.
Comment 1 Wayne Davison 2004-10-11 03:56:54 UTC
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.
Comment 2 Wayne Davison 2004-10-11 04:01:21 UTC
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.
Comment 3 Wayne Davison 2004-10-14 12:19:01 UTC
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.