I created a systemd service file for rsyncd.
systemd is a sysvinit replacement (see  for more information).
One of the goals of systemd is to encourage standardization between different
distributions. This means, while I also submitted a ticket in Debian GNU/Linux,
I would like to ask you to accept this service file as the upstream
distributor, so that other distributions can use the same service file and
don’t have to ship their own.
If you have any questions, please do not hesitate to contact me.
Created attachment 6823 [details]
rsync.service file snagged from debian bug
It should be awesome to also include a socket unit file, so that rsync could be socket activated. Actually, it will only support inetd-style activation, but it will be an open door to support a full socket based activation
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.
On my Arch Linux system this is actually /etc/rsyncd.conf and according to the man pages the 'd' is correct. Is this a typo or is Debian actually using /etc/rsync.conf for some reason?
I simply removed this line from my service file, but imho it makes sense to include it.
Nevertheless, apart from the exit code issue the service file works fine for me and I would also like to see this upstream.
is there a bug report for the exit code issue / should I create one?
$ dpkg -l rsync
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Description
ii rsync 3.0.9-1 fast, versatile, remote (and local) file-cop
$ $ cat /lib/systemd/system/rsync.service
Description=fast remote file copy program daemon
ExecStart=/usr/bin/rsync --daemon --no-detach
So no, Debian is _not_ using rsync.conf.
That was written in the original bug report requesting the systemd support, but that was not quite correct, as I commented in that bug report; see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=639632
I created a separate bug report regarding the exit code issue since this should be fixed regardless of systemd:
(In reply to comment #3)
> 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.
I say it's a bug in systemd that it doesn't allow for daemons to behave however they may happen to behave.
(In reply to comment #7)
> (In reply to comment #3)
> > 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.
> I say it's a bug in systemd that it doesn't allow for daemons to behave however
> they may happen to behave.
When I tell any daemon that it should stop, I expect it to exit with exit code 0 when it was stopped without any problems. In case there was an error while stopping (say the disk is mounted read-only and some data cannot be written), I expect it to return with an error code.
Therefore, I think rsyncd should be changed, not systemd :).
Created attachment 9711 [details]
I have correct the original rsync.service file.
As a point of reference, both Fedora 20  and Debian Sid use this rsync.service as their systemd service file.
Thanks for the file. I've gone ahead and included it in packaging/systemd dir.