Michael Stapelberg’s Debian Blog

Survey answers part 3: systemd is not portable and what this means for our ports (2013-07-13)

This blog post is the third of a series of posts dealing with the results of the Debian systemd survey. I intend to give a presentation at DebConf 2013, too, so you could either read my posts, or watch the talk, or both :-).

The second-biggest concern in the survey results was that systemd is not portable to non-Linux systems, for example Debian GNU/kFreeBSD or Debian GNU/HURD. For convenience, I will from now on write “kFreeBSD” when I really mean all non-Linux ports.

systemd not being portable is not an arbitrary decision

Some people seem to think that the systemd upstream is just hostile to users of other operating systems when they hear that systemd is not portable. However, keep in mind that Lennart, Kay and other contributors have considerable experience with writing portable software such as Avahi and PulseAudio.

The decision to only support Linux in systemd was thus not taken lightly. systemd’s design requires many kernel features and certain semantics (e.g. procfs is not enough, /proc/$PID/exe needs to be supported), which are currently only available on Linux. Point 15 of Lennart’s blog post 0pointer.de/blog/projects/the-biggest-myths.html contains an incomplete list of these features.

Maintaining portable code increases complexity

Since systemd is written in C, the canonical way to write portable code is by using conditional compilation, for example with ifdef statements. That makes the code harder to understand and reason about, but more importantly it blows up the test matrix. It also requires any new change to be tested on all supported systems, which is not feasible for most contributors. I think everybody agrees keeping complexity low is a good thing.

What are the implications for our non-Linux ports?

We, the Debian project, have two realistic options in my point of view:

We stay with sysvinit, the least common denominator, forever. We use a modern init system such as systemd on Debian GNU/Linux.

In case we go with the first option, Debian will diverge more and more from virtually every other Linux distribution. This also means we are stuck with the limited features and capabilities that sysvinit has. A modern operating system needs to be able to adapt to a changing environment and the once static world in which sysvinit was developed has become much more dynamic.

In our opinion, the only reasonable choice is the latter option: use systemd on Debian GNU/Linux.

How will this work?

In the short-term future, maintainers add systemd support to their packages. This does not imply dropping sysvinit support. As outlined in my post about the transition, systemd service files can coexist with sysvinit scripts.

In the mid-term future, both sysvinit and systemd are supported — this is the only way we can do a gradual transition, and Debian clearly does not want a flag day.

In the long term, we could switch the default from sysvinit to systemd on Debian GNU/Linux, in case we agree that’s a reasonable decision at that time. Non-Linux ports will still use sysvinit.

For individual maintainers, this means they need to support two init systems. Luckily, systemd service files are usually really simple, but there still is additional maintenance work such as testing whether your service actually starts when using systemd. We think this maintenance overhead is justified due to the advantages a modern init system brings. Of course, not every maintainer can arrange it to install systemd and test his/her package. You are invited to contact us at pkg-systemd-maintainers@lists.alioth.debian.org at any time and we can help you out.

Furthermore, automation can be introduced (and we have a proof of concept) to make it easier to spot mistakes and perform some simple tests, such as whether the service can be started.

A concern that was voiced is that as sysvinit usage decreases, the init scripts would bit-rot and stop working at some point. If that happens, we rely on the users to file appropriate bug reports. This is no different from the situation today — it is not feasible for maintainers to test every single combination of features all the time.

Ports are different and that diversity is good

The FreeBSD kernel and the Linux kernel are different, and each kernel provides distinct features that the other kernel does not have. As an example, Linux provides cgroups, which are heavily used by systemd. The FreeBSD kernel in turn offers the packet filter “pf”, which is not available on Linux. There certainly is value in having common infrastructure. But there also is value in providing the best features that each platform has to offer — in case of Linux, that is clearly systemd as an init system IMO.

Conclusion

systemd is not portable because it relies on features only the Linux kernel provides — an example is cgroups, which systemd uses to track processes in a reliable way. Not embracing these features and staying with sysvinit indefinitely is not a viable option if Debian wants to remain relevant for today’s demands. In the short term, the migration to systemd will cause additional maintenance effort for individual package maintainers, but it will pay off in the long term.