[Bug 8416] Please include systemd service file

Brian K. White brian at aljex.com
Sat Nov 26 20:32:05 MST 2011

On 11/25/2011 11:23 PM, samba-bugs at samba.org wrote:
> https://bugzilla.samba.org/show_bug.cgi?id=8416
> --- Comment #3 from Cristian Rodríguez<crrodriguez at opensuse.org>  2011-11-26 04:23:34 UTC ---
> There is a quirk to be aware of in this systemd unit.
> Rsync areturns with non-zero (code 20) exit code when the running service is
> stopped, so systemctl stop rsync.service will make the service to enter failed
> state and not stopped state.
> This is IMHO a bug in rsync when running as daemon. most if not all of other
> daemons return 0 exity code on SIGTERM.

Classic user confusion, messages != warnings != errors.

There can be more than one set of conditions or reasons why a program 
exited without it being necessarily an error or failure. Exit 0 does 
commonly mean success, and exit 1 does commonly mean false or failed, 
but exit >1 may mean anything.

Exit values are meant to be informative. 0, being a single value, is not 
expressive enough to describe all the possible meanings for exiting that 
aren't necessarily errors or failures.

It's no bug in rsync. It's just one more of many design limitations and 
broken assumptions of systemd, for all it's admitted improvements over 
sysv init.

Systemd should provide a mechanism by which the service file author can 
tell systemd how a particular daemon behaves, instead of assuming all 
daemons only behave exactly one way and that any other way is 
automatically wrong.

Petition systemd to add that feature, or dig into their docs and make 
sure such a mechanism doesn't already exist, or write a wrapper script 
around rsync to satisfy systemd.

It might be a feature request to add a "systemd mode" to rsyncd to tell 
it "only exit with 0 unless there was really a failure or error"
But that's a feature request to pacify something else for the 
convenience of users, not a bug that needs fixing.


More information about the rsync mailing list