Bug#727708: systemd and upstart, a view from a daemon Debian maintainer
As I have mentioned, I tried adapting userv to systemd and upstart. I
have already reported on my experience with the core daemon code.
In this message I'll deal with the config fragments ("units" and "jobs"
as they call them), and the Debian-specific packaging.
I'm treating the config fragments as part of the packaging, rather
than as something upstreamish, because in practice they are inherently
un-debuggable without access to a system running the corresponding
daemon. They are also small enough that any distro which cares could
easily ship their own (and might need to).
I found configuring upstart to be utterly trivial. There was little
opportunity for error. More guidance in debian-policy would be a good
idea, including perhaps a reference to some example packages.
The machinery neeeded in the package was also trivial. For userv, I
didn't need to modify the maintainer scripts at all; the existing
invocations of update-rc.d and invoke-rc.d DTRT. (userv is an old
package whose packaging predates debhelper, let alone dh(1).) I had
to add a new call to dh_installinit and drop the upstart job file in
the correct location.
Debugging things was also very easy. The logfiles were where I
expected they would be and had the expected contents.
I have read the documentation for the socket activation approach.
Inevitably this would be a bit more fiddly but it seems like it would
have been nearly as simple.
systemd was rather more complex.
There was less support from the Debian policy manual. Perhaps there
is some other systemd Debian packaging guidance somewhere which I
didn't find.
The unit files were somewhat harder to write. It wasn't just that the
systemd unit file offered a great many more options, although that was
a factor. The two-unit split of systemd socket activation was more
fiddly. And systemd wants each directive to be in a particular
"[section]".
The package maintainer scripts exposed more complexity too. It was
necessary to add new systemd-specific calls to "deb-systemd-helper".
The boilerplate required here was too much to simply include in my
existing scripts, so I had to switch the package to using
debhelper-generated maintainer scripts. (This is of course a good
idea in the long run, but it would be better to require less
yak-shaving.)
Part of this complication results from systemd's curious approach to
deciding which services need to run in which runlevel (or equivalent):
once again we are expected to drop some symlinks into a magic
directory - and provided with semiautomatic utilities for doing this.
Also, the approach to the systemd integration introduces a new runtime
package dependency on "init-system-helpers", which despite its
generic-sounding name actually contains only helpers for systemd and
is maintained in Debian by the systemd maintainers.
Perhaps it would be possible to have more sophisticated maint script
fragments which will cope if deb-systemd-helper is not installed -
but, then, of course, the systemd maint script fragments will be even
more complicated.
I'm not sure at the moment whether I want to ship the systemd
integration in my package :-/.
Ian.
Reply to: