If two rsync daemons using the same pid file are started, the second one should notice the pid file and quit. Right now, the second daemon overwrites the pid file, fails to listen on the port, and then removes the pid file, leaving the first daemon running without a pid file (harder to kill automatically). The fix is as simple as adding O_EXCL to the do_open(lp_pid_file(), ...) call in clientserver.c.
Created attachment 2181 [details] patch I can reproduce this issue. The described change fixes it: # /etc/init.d/rsyncd start # cat /var/run/rsyncd.pid 9913 # pgrep rsync 9913 # /etc/init.d/rsyncd zap (trick the rc system to think the service is stopped) # /etc/init.d/rsyncd start # cat /var/run/rsyncd.pid 9913 # pgrep rsync 9913
This is now fixed in CVS.
I think this patch is flawed as it seems to lack a mechanism to check for stale PIDs. On a Windows system running rsync 3.0.0pre1, rebooting after a crash results in: 2007/10/19 11:55:45 [127] rsync: failed to create pid file /cygdrive/c/var/pgm/log/rsyncd.pid: File exists (17) 2007/10/19 11:55:45 [127] rsync error: error in file IO (code 11) at clientserver.c(857) [receiver=3.0.0pre1] The PID in rsyncd.pid is no longer pointing to a process. Should I open a new bug?
I left out the breaking of a stale lock file on purpose, as I could imagine that some folks wouldn't want auto-breaking. Those that do can easily add in either (1) file-removal at boot or (2) stale lock file checking in the daemon startup script. However, maybe it should be an option -- if you want to suggest that, feel free to open an enhancement bug.