Debian reconsiders init-system diversity

This article brought to you by LWN subscribers Subscribers to LWN.net made this article — and everything that surrounds it — possible. If you appreciate our content, please buy a subscription and make the next set of articles possible.

Many community-based Linux distributions have made the decision to switch to systemd, and most of those decisions were accompanied by lengthy, sometimes acrimonious mailing-list discussions. No distribution had a harder time of it than Debian, though, where arguments raged through much of 2013 before the Debian Technical Committee decided on systemd in early 2014. Thereafter, it is fair to say, appetite for renewing the init-system discussion has been low. Now, though, the topic has returned to the fore and it would appear that the project is heading toward a new general resolution (GR) to decide at what level init systems other than systemd should be supported.

The new systemd discussion had been simmering for some time before flaring up in late 2018 when it became clear that the project had been unable to fully support systemd alternatives due to a lack of developer interest. The current discussion, instead, is a direct result of Debian project leader Sam Hartman's Bits from the DPL posting on October 29. Therein, he stated his belief that a new general resolution on init-system support is necessary, and that he would be proposing one in the near future.

The immediate motivation for a reconsideration would appear to be the proposed addition of elogind, a standalone fork of the systemd-logind daemon, to Debian. Elogind would provide support for systemd's D-Bus-based login mechanism — needed to support small projects like the GNOME desktop — without the need for systemd itself. The addition of elogind has been controversial; it is a difficult package to integrate for a number of reasons. Much of the discussion has evidently been carried out away from the mailing lists, but some context on the problem can be found in this bug report. In short: merging elogind appears to be complex enough that it would be hard to justify in the absence of a strong commitment to the support of non-systemd init systems. It seems possible that this commitment no longer exists across the distribution as a whole; the purpose of a general resolution would be to determine whether that is the case or not.

Feature pressure

Unsurprisingly, Debian developers have a variety of opinions on this issue. This response from Russ Allbery is worth reading in its entirety. He argues that the 2014 decision (of which he was a part) never really nailed down the project's position toward other init systems. That was a necessary compromise at the time, he said, but it is causing stress now: "while I feel somewhat vindicated by the fact that this didn't immediately fall apart and has sort of worked, I think it's becoming increasingly untenable". The time has come, he says, to make the project's position clear so that developers can and will do the right thing:

If we're really going to continue to fully support sysvinit, we should commit to doing so clearly and empower people to test that support and report bugs of appropriate severity (and also to create a stronger incentive for making that support easier to achieve). If we're not, we should unambiguously free people from doing additional work that they don't want to do and can't test easily, and also more clearly communicate the project's intentions so that our partners like Devuan can make informed decisions about how to proceed.

Josh Triplett zeroed in on one of the issues that is testing the init-system peace now. There is, he said, an increasingly long list of features that are only available with systemd, and application developers want to use those features:

Today, people can't just use systemd-tmpfiles as their means of creating files at startup, because they have to have a fallback for the non-systemd case. Today, people can't use systemd persistent timers in place of cron (and in place of anacron's "wake up periodically" approach). [...] Systemd user sessions, socket activation, sysusers, dynamic users, systemd-homed, temporary directory setup, transient units, anything talking to the slice or control group APIs, containerization, firstboot, systemd's whole "preset" system-wide configuration and policy mechanism for admins to say "what services do I want launched when installed and what services do I want to leave stopped until I configure them", "stateless system" capabilities, and I'm probably forgetting another dozen.

The responses to this argument took a couple of different approaches. Ted Ts'o described those features as "the 'embrace, extend, and extinguish' phenomenon of systemd which caused so much fear and loathing". Debian has avoided much of this stress until now, he said, because it ships a relatively old version of systemd, but that won't last forever. Upstream developers are going to use newer systemd features, and Debian will have to accept that if it wants to package and ship their code. "I don't think we have a choice but acknowledge reality and accept that some packages may simply be incompatible with alternative init systems". The situation doesn't make him happy, he said, but there is little to be done about it.

Allbery, instead, suggested that the project could decide on a set of interesting systemd features, then create non-systemd implementations of those features where necessary. That is essentially what is being done with elogind, for example. All init systems could be made to parse systemd unit files, and there would be a minimal set of directives they would be expected to support. There would, in effect, be a definition of the ABI an init system must support, rather than any rules about specific systems. Done properly this approach could ease the feature pressure, but there is one little problem:

Of course, this approach is not viable if it turns out that too few people are interested in init system diversity sufficiently to do the reasonably substantial implementation work required to maintain a competing implementation of the systemd unit features we care about.

Some, like Ian Jackson, claimed that much of this functionality already exists and works. Svante Signell also argued that the systemd alternatives are well maintained and that Debian should remain open to contributions from developers who are working on those alternatives.

Others, including Triplett, said that not only do the developers of other init systems lack the desire to implement systemd features, but they argue that those features should not exist in the first place. That, Allbery added, is the question that the project has to answer: what will be Debian's policy toward software that requires features that will be specific to systemd? Should there be a specific subset of systemd features that Debian software will be allowed to depend on, with the idea that alternative init systems will eventually gain implementations of those features?

The first GR draft

Hartman posted a draft general resolution on November 7 that does not directly address Allbery's question. It focused strongly on init systems, rather than support for advanced systemd features; there are three alternatives:

"Affirm init diversity": running init systems other than systemd is an important project goal, and provision of init scripts would remain mandatory.

"Systemd but we support exploring alternatives": systemd would be the preferred init system, but alternatives would remain important; elogind is given as an example of the sort of project that should be supported. Hartman posted another message with a detailed description of what this option might imply.

"Systemd without diversity as a priority": there would be no requirement to support anything but systemd in Debian.

Hartman thus appears to have left out Allbery's suggestion of defining an init-system ABI entirely. It should be noted, though, that this is explicitly a draft; it is likely to evolve considerably before it reaches the point where the project will vote on it.

There is one final bit of context to consider as part of this vote: according to Marco d'Itri, it has already happened. "We have already voted with apt: less than 1% of new installs use sysvinit". That suggests a relatively low level of interest in systemd-free Debian. Perhaps users with that interest have moved to Devuan but, to all outside appearances, progress there has slowed considerably since its developers fell out with each other in April. Even if Debian chooses to continue to support multiple init systems, it is not clear that the development effort to make that support work will be there.

The free-software community values diversity and choice in its systems. But we also value standardization and the progress that can be made when we all focus our efforts on a single system. Many parts of the Linux system are essentially monocultures: examples include the kernel, the C library, and, until relatively recently, the compiler. There are strong arguments in favor of both standardization and diversity. In the case of GCC, the lack of competition is often cited as a cause for a long period of relative stagnation. If one looks at desktop environments, instead, it is often said that the scattering of developer effort has prevented the success of the Linux desktop as a whole.

It would thus seem that there is no obvious answer to the question of init-system diversity, regardless of how one feels about systemd in particular. Most community distribution projects have long since decided that they lack the resources (and maybe the desire) to support multiple init systems. Most of those, especially the larger ones, have settled on systemd, even if they feel that a viable alternative to systemd would be good to have. Debian has, so far, been an exception to this trend. It will be interesting to see whether the project has the will and the development resources to continue on that course.

