Bug 8416 - Please include systemd service file
Please include systemd service file
Status: RESOLVED FIXED
Product: rsync
Classification: Unclassified
Component: core
3.1.0
All All
: P5 normal
: ---
Assigned To: Wayne Davison
Rsync QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-08-28 20:46 UTC by michael+samba
Modified: 2014-02-24 18:18 UTC (History)
0 users

See Also:


Attachments
rsync.service file snagged from debian bug (187 bytes, text/plain)
2011-08-29 06:26 UTC, Wayne Davison
no flags Details
rsync.service (188 bytes, application/octet-stream)
2014-02-24 00:01 UTC, David Farning
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description michael+samba 2011-08-28 20:46:39 UTC
Hello,

I created a systemd service file for rsyncd.
systemd is a sysvinit replacement (see [1] 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.

Thanks!
Best regards,
Michael

[1] http://en.wikipedia.org/wiki/Systemd
Comment 1 Wayne Davison 2011-08-29 06:26:49 UTC
Created attachment 6823 [details]
rsync.service file snagged from debian bug
Comment 2 Adrien CLERC 2011-11-06 15:45:55 UTC
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
Comment 3 Cristian Rodríguez 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.
Comment 4 mus.svz 2012-05-10 14:52:32 UTC
ConditionPathExists=/etc/rsync.conf

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?
Comment 5 Paul Slootman 2012-05-10 15:29:07 UTC
$ dpkg -l rsync
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ 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
[Unit]
Description=fast remote file copy program daemon
ConditionPathExists=/etc/rsyncd.conf

[Service]
ExecStart=/usr/bin/rsync --daemon --no-detach

[Install]
WantedBy=multi-user.target


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
Comment 6 mus.svz 2012-05-31 13:07:14 UTC
I created a separate bug report regarding the exit code issue since this should be fixed regardless of systemd:
https://bugzilla.samba.org/show_bug.cgi?id=8967
Comment 7 Brian K. White 2012-06-01 17:48:00 UTC
(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.

-- 
bkw
Comment 8 michael+samba 2012-06-02 08:14:43 UTC
(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 :).
Comment 9 David Farning 2014-02-24 00:01:26 UTC
Created attachment 9711 [details]
rsync.service
Comment 10 David Farning 2014-02-24 00:07:47 UTC
I have correct the original rsync.service file.

As a point of reference, both Fedora 20 [1] and Debian Sid use this rsync.service as their systemd service file.

Thanks
David


1- http://pkgs.fedoraproject.org/cgit/rsync.git/tree/rsyncd.service?h=f20
Comment 11 Wayne Davison 2014-02-24 18:18:18 UTC
Thanks for the file.  I've gone ahead and included it in packaging/systemd dir.