Bug 3554 - Second copy of same rsync daemon should notice pid file and quit
Second copy of same rsync daemon should notice pid file and quit
Product: rsync
Classification: Unclassified
Component: core
All All
: P3 normal
: ---
Assigned To: Wayne Davison
Rsync QA Contact
Depends on:
  Show dependency treegraph
Reported: 2006-02-24 19:16 UTC by Matt McCutchen
Modified: 2007-10-22 16:33 UTC (History)
2 users (show)

See Also:

patch (444 bytes, patch)
2006-10-11 17:34 UTC, Simon Stelling
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Matt McCutchen 2006-02-24 19:16:01 UTC
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.
Comment 1 Simon Stelling 2006-10-11 17:34:15 UTC
Created attachment 2181 [details]

I can reproduce this issue. The described change fixes it:

# /etc/init.d/rsyncd start
# cat /var/run/rsyncd.pid
# pgrep rsync
# /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
# pgrep rsync
Comment 2 Wayne Davison 2007-09-30 21:30:21 UTC
This is now fixed in CVS.
Comment 3 Tom Metro 2007-10-22 12:02:12 UTC
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?
Comment 4 Wayne Davison 2007-10-22 16:33:06 UTC
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.