Upstreaming systemd units

More and more distributions ship unit definition files as a part of systemd integration. Sadly, upstreaming effort is very low profile and downstream units begin to diverge. I’ve spent some time during last month to push unit definitions upstream into the software I use.

Starting with ladvd. Actually, Sten merged service unit definition about a year and a half ago. Recent changes in systemd allowed unit to be simplified.

Next was hdapsd. Evgeni preliminary accepted patches, so it seems systemd unit will make into the first hdapsd commit in three years. Probably together with other patches waiting, like HP and Apple notebooks support. My patch contains udev rule, as this is an example of hardware-activated service.

I also patched rrdcached, implementing socket-activation and providing two units definitions. Tobias merged my patches in trunk. This gives us timely, on-demand start up and no lost connections even during rrdcached restart.

uptimed will ship unit files in 0.3.18, also. Radek is the new upstream and he happily took patches.

I also have got a patch for aiccu, but I did not send it. There was no upstream activity in the last 5 years and I'm not entirely happy with my patch, as it disturbs platform-agnosticy. I've implemented Type=notify behaviour, marking unit active only if tunnel was established. That makes After=aiccu.service work in expected ways.

Writing unit definition is simple. Hooking up autotools stuff is more complicated, but man 7 daemon contains very helpful snippets. You may need to add something like AC_OUTPUT([etc/mydaemon.service]) to mangle into mydaemon.service by replacing ExecStart=@prefix@/sbin/mydaemon with whatever prefix was passed to ./configure.

If you do not want to use helper functions provided by systemd, you can reimplement logic directly in the application. For example, look at this simple patch implementing socket activation in iodine.

It is often useful for a daemon to open a default config file. Location of this file should be provided at build time. Debian tend to use /etc/mydaemon/mydaemon.conf location, while Fedora is more about /etc/mydaemon.conf. Removing the path from the unit file makes it simpler and more reusable between distributions.

You want to test the unit file in the field, typically in Rawhide or similar distribution. After a release cycle or two, when you have all bugs ironed out, you should submit unit file upstream.


Comments powered by Disqus