Init system support in Debian

We're bad at marketing
We can admit it, marketing is not our strong suit. Our strength is writing the kind of articles that developers, administrators, and free-software supporters depend on to know what is going on in the Linux world. Please subscribe today to help us keep doing that, and so we don’t have to get good at marketing.

The "systemd question" has roiled Debian multiple times over the years, but things had mostly been quiet on that front of late. The Devuan distribution is a Debian derivative that has removed systemd; many of the vocal anti-systemd Debian developers have switched, which helps reduce the friction on the Debian mailing lists. But that seems to have led to support for init system alternatives (and System V init in particular) to bitrot in Debian. There are signs that a bit of reconciliation between Debian and Devuan will help fix that problem.

The Devuan split was acrimonious, much like the systemd "debate" that preceded it. Many bits were expended in describing the new distribution as a waste of time (or worse), while the loudest Devuan proponents declared that systemd would cause the end of Debian and Linux as a whole. Over time, that acrimony has mostly been reduced to random potshots (on both sides); there is clearly no love lost between the pro and anti sides (whether those apply to systemd, Devuan, or both). Some recent developments have shown that perhaps a bit of thawing in relations is underway—that can only be a good thing for both sides and the community as a whole.

Holger Levsen alerted the debian-devel mailing list that the Debian "Buster" (i.e. Debian 10) release was in danger of shipping with only partial support for running without systemd. The problem is that two packages needed for running with System V init (sysvinit-core and systemd-shim) are not really being maintained. The shim is completely unmaintained and sysvinit-core has been languishing even though it has two maintainers listed.

While Thorsten Glaser at first downplayed the problems, he changed his tune somewhat after Ben Hutchings pointed out that the sysvinit package has "many open bugs with patches that have not been applied or answered". The problem goes even deeper than that, according to Andreas Henriksson:

I think sysvinit is getting closer and closer to being removed. Usually the debian way is to say that whoever reaps the benefits gets to do the work. That hasn't been the case for sysvinit for [at least] several years now. The only reason sysvinit is still around is because people who don't use it and largely don't care about it keeps doing the work to keep it afloat (while people who use it keep repeating "[everything] is fine, it's mature" and stick their heads in the sand).

And, as Petter Reinholdtsen explained, the sysvinit "team" is really just him at this point. He is "lacking both the required spare time and interest to do [a] good job, but still try to fix the gravest problems while waiting for someone with time and interest to [adopt] the packages". He too is concerned that the packages will be removed before long. So Jonathan Dowland suggested looking elsewhere for help:

Is it worth interested parties reaching out to the Devuan project regarding person-power for sysvinit maintenance? As a derivative distribution, I imagine their lives would become much harder if we did drop sysvinit; they would have to pay the cost of maintaining the sysvinit package themselves (which is what I am proposing they do now) *as well* as a rapidly growing delta of sysvinit-support/initscripts in lots of other packages, as they steadily rotted in Debian.

That set off a fairly predictable round of Devuan bashing, along with concerns that inviting Devuan developers to work in Debian would bring on a return of the mailing list battles of old. But it also resulted in a reply from Enzo Nicosia (also known as "KatolaZ"), who is one of the Devuan "Caretakers" team:

The problem that spurred this thread is that sysvinit needs a maintainer. That's why some of us are here: our intention is to help with maintaining sysvinit in Debian if possible, since we will keep maintaining it in Devuan nevertheless. You can still decide you don't want this kind of help because we stink or you find Devuan "toxic" (even if this would be against some of the principles we should instead agree upon). That could be fine, if motivated by a solid reasoning, and not just by a flame.

In the last four years there has been hatred from both camps (Debian vs Devuan), and there is no doubt that most of that could/should have been avoided on both parts. Grepping through email archives and [resurrecting] posts from 3 or 4 years ago won't help to move on, though.

I am not interested in chit-chat or flames, because those don't get packages released. The only reason I am here is that sysvinit is effectively getting kicked off Debian, and I think I can help avoiding that.

Several Debian developers were ready to let bygones be bygones and welcomed any effort toward keeping sysvinit alive in Debian. Ian Jackson invited Nicosia to a new debian-init-diversity mailing list. That mailing list has been expressly set up to avoid the hostility on (some) Debian mailing lists, Jackson said. It would appear to be the place where non-systemd init systems will be discussed and developed moving forward.

Back in debian-devel, there were other sysvinit proponents (such as Benda Xu) who did not see any real problems with the sysvinit package. But Reinholdtsen was quick to point out that attitude as helping to push sysvinit out of Debian. Beyond that, as Martin Pitt noted, the problems are far more widespread than simply being confined to the sysvinit package:

[...] the *real* maintenance is in all the packages that *ship* SysV init scripts.

SysV init leaves all the really hard problems to these, as it cannot really do much by itself. That's a fact that people that keep yelling "but SysV init was so easy!" keep finessing..

So "how many RC bugs does sysvinit have" is a completely useless metric IMHO.

Bernd Zeimetz brought up a related issue: "the typical package maintainer won't test initscripts". Many of them won't even have access to a system that runs sysvinit, he said, so they can't test them well. In another part of the long thread, though, Philipp Kern asked: "Could someone reiterate about what the current state of init diversity is supposed to be?" Russ Allbery had some thoughts on that:

I think a package of a daemon that does not inherently require any systemd-specific features and would work straightforwardly with sysvinit, but has only a systemd unit file and no init script, is not only buggy but RC-buggy. That's what Policy currently says.

It is quite easy to write a sysvinit init script for most daemons that will basically work. I don't think the maintainer is obligated to do much more than that (for instance, I don't think you need to try to duplicate systemd hardening configuration or other features that are quite challenging to do under sysvinit without more tool support, although some of that may be coming in start-stop-daemon).

He suggested that maintainers could test the init scripts by moving the systemd unit file aside and have systemd use the init script. "For nearly all daemons that don't involve tight system integration, this will be more than adequate." In another message, he explained that providing an init script is, at least partly, a gesture of goodwill within the Debian community:

My personal concern is more about the social community of the project than about the technical details. I consider providing an init script even if I don't personally use sysvinit to be extending the hand of community and solidarity to other Debian community members who use it. To say to them that their concerns have been heard and supported, even if I don't agree with their concerns. Personally, I find that extremely important, a principle that's as important as the technical quality bar we try to reach in our packages.

Overall, the dialog was relatively positive and the outcome may well lead to better maintenance of sysvinit for both Debian and Devuan moving forward. Given a little more time (and water under the bridge), Devuan's users could provide the testbed for the init scripts, which will obviously help Devuan, but will also be a boon for any Debian users of sysvinit. There is still likely to be something of chasm between the two distributions, but any rapprochement should be welcome news to most. In truth, what separates the two is pretty trivial in the grand scheme of things—the flames and acrimony notwithstanding.