Add nice and ionice

[Natrinicle]

I needed access to nice and ionice levels on my Debian rsync server.
Templatized the defaults file so that these were accessible. Also
added nice to xinetd service and changed the server to ionice and the
server args to the ionice level followed by the rsync path and
previously existing arguments.

[TheMeier]

This doesnt't work since wheezy wich is already oldstable since rsync is started with a native systemd unit. Actually the content of the default file seems to be completly ignored there?!
A better way would be to create a systemd drop-in unit and set IOSchedulingPriority/IOSchedulingClass

[Natrinicle]

You're right. I was testing with Ubuntu 14.04 which has both a sysvinit and a systemd init script and it appears to be using the init.d script over the systemd. This was causing the nice and ionice settings to be loaded. I'll work on the systemd unit.

[Natrinicle]

Had to modify the ionice parameter since IOSchedulingClass takes 0-3 or the corresponding names while xinetd (ionice) and rsync defaults both take -c[0-3]. Removed the -c from the parameter default value and added it to the xinetd service and defaults template.

Since systemd isn't available on all systems, I added an exec to check for the /etc/systemd/system directory before this module creates the rsync.service.d directory and the (io)nice conf files.

[TheMeier]

Hmm:

Q: I have a native systemd service file and a SysV init script installed which share the same basename, e.g. /usr/lib/systemd/system/foobar.service vs. /etc/init.d/foobar -- which one wins?

A: If both files are available the native unit file always takes precedence and the SysV init script is ignored, regardless whether either is enabled or disabled. Note that a SysV service that is enabled but overridden by a native service does not have the effect that the native service would be enabled, too. Enabling of native and SysV services is completely independent. Or in other words: you cannot enable a native service by enabling a SysV service by the same name, and if a SysV service is enabled but the respective native service is not, this will not have the effect that the SysV script is executed.

from https://www.freedesktop.org/wiki/Software/systemd/FrequentlyAskedQuestions/

That is why I said:

Actually the content of the default file seems to be completly ignored there?!

Are you really sure your Ubuntu 14.04 prefers the init script over the unit?

[TheMeier]

Instead of the Exec i would rather make a platform based switcharoo eg like done here https://github.com/deric/puppet-zookeeper/blob/master/manifests/params.pp

[Natrinicle]

I rewrote the exec into a platform based massive case statement though I'm not certain I like that better as it won't catch someone who's installed systemd on a system that doesn't come with it by default.

Ubuntu 14.04 appears to include systemd service files in it's packages (likely upstream packagers getting ready for the changeover or including both to be safe) but is running upstart and thus ignores those service files altogether.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}