Which init system for Debian?

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.

The Debian project is no stranger to long, vehemently argued email threads, though, like the rest of us, Debian developers appear to be getting older and calmer as time goes by. If there were to be an intense thread now, one might think that the recent shift to XFCE as the default window system might be the cause. Indeed, there was some discussion of that topic, but that thread was easily buried by the hot-button issue that almost all distributions appear to need to debate at length: which init system to use. This is not the first time Debian has argued over init systems (see this 2011 article , for example), but, just maybe, it might be the last.

The job of the init system is reasonably straightforward: it is the first process that runs once the kernel boots. The init system is responsible for starting the various services that the system needs to run, preferably quickly and in the proper order. It should assist the administrator with the management of those services as the system runs, and shut things down cleanly when the system needs to go down. Traditionally, this task has been handled by a relatively simple init daemon and a large collection of service-specific shell scripts. More recently, a number of alternatives have come forward, and most distributions have either switched to one of them or plan to in the near future. Debian, however, remains with the traditional System V init system ("sysvinit") as its init system.

The process

While Debian has debated init systems (and systemd in particular) a few times in the past, the current discussion has a certain level of urgency to it. One contributing factor to this urgency is the perception that the GNOME desktop environment is developing dependencies on systemd that will make it harder to run GNOME under any other init system. Add to that an increasing sense that sysvinit is not up to the challenges of managing a contemporary Linux distribution. Finally, the current release plan calls for the "Jessie" release to be frozen in almost exactly one year; most Debian developers seem to agree that, if a change is to be made, the work needs to begin now if it is to be stable by the Jessie freeze date.

Thus, it is not surprising that the Debian community has pursued the init system debate with extra vigor this time around. The extensive discussions have made a lot of developers' opinions clear, but they have not led to any sort of consensus around which a decision can be made. When a contentious issue involves a single package, Debian has a long tradition of deferring to the package's maintainer. But no such situation holds here; instead, the debate reaches to the core of how the distribution is to be structured; it affects the design of the distribution as a whole and details in many other packages. Given the lack of consensus, it seems clear that, somehow, a decision will have to be reached by a different means.

In the past, the preferred means for reaching closure on divisive issues in Debian has been the general resolution: a vote of all Debian developers. A general resolution was duly proposed this time around as well, but the idea received little support in the end. Former project leader Stefano Zacchiroli described his opposition this way:

GRs should be used for societal and policy decisions. Using GRs for *technical* decision is stupid. We really need to stop thinking that every single member of the Debian project, just because he/she is a DD, has a clue on every single technical matter that go on in the project.

Most people seemed to agree with this position, so, at this point, it appears that no such resolution will take place. Instead, the issue has been referred to another longstanding Debian institution: the technical committee. This committee serves as a sort of high court for the resolution of technical disagreements that cannot otherwise be worked out. In general, this committee is held in high regard; its decisions command respect within the Debian community. This particular decision, though, may test just how far that respect goes.

One potential problem has to do with the membership of the committee: Bdale Garbee is the chair, while the other members are Russ Allbery, Don Armstrong, Andreas Barth, Ian Jackson, Steve Langasek, and Colin Watson. It did not take long for somebody to point out that two of those members (Steve and Colin) are current Canonical employees. Since Canonical is heavily invested in the upstart init system, it may not be unreasonable to wonder if those two members might not come under some workplace pressure to vote in upstart's favor. Given that Steve is the Debian upstart maintainer and is on record as strongly supporting that option already, there appears to be little doubt about which way his vote will go.

That said, both Steve and Colin appear to have a great deal of respect in the Debian community; both have been Debian developers for longer than they have been Canonical employees. Several other developers have expressed their belief that all members of the technical committee will approach the question with the best interests of the Debian project in mind; calls for specific members to abstain from voting on this issue have received little support.

The decision

The question is currently phrased as a choice between five options:

Stick with the existing sysvinit system. Systemd Upstart OpenRC Support multiple init systems in one configuration or another

Many of the technical arguments in favor of one system or another have been heard many times before; there would be little value in rehashing them all here. For the curious, this Debian debate page is where each camp is marshaling its arguments for the technical committee; if the committee is a sort of supreme court, then that page is where the briefs are filed. Anybody who is interested in the details of each group's arguments can find them all there.

There are a couple of interesting Debian-specific issues at play here, though. One of those is tied to the fact that Debian ships distributions based on multiple kernels. The Debian GNU/kFreeBSD distribution is based on the FreeBSD kernel, while Debian GNU/Hurd uses the GNU project's Hurd kernel. Since neither systemd nor upstart supports non-Linux kernels, adoption of either of those options would create some pain for the non-Linux projects. Of the two, upstart appears to be more open to adding non-Linux support than systemd, whose developers have gone on record as being opposed to code for portability. How much that matters remains to be seen; suffice to say that opinions vary on how much influence the non-Linux ports should have on this decision.

Debian developers are also concerned about the possibility of being pushed around by other distributions. Systemd is seen by many as a Red Hat project, despite the fact that it has a significant community of contributors that reaches far beyond that company. Upstart, too, is seen as tightly tied to its corporate sponsor — a company that, in addition, is Debian's largest and most famous downstream distributor. The Debian community values its independence highly and is not afraid of charting its own path. The same mindset that leads to, say, the choice of Exim as the default mail transfer agent could encourage a choice of a less popular init system.

All of this leaves the Debian technical committee with a difficult decision. It is hard to imagine an outcome that does not leave a fair amount of unhappiness in its wake. This decision can be expected sometime fairly soon; the process of putting together the position pages appears to be about done, and the task of implementing the final decision is looking increasingly urgent. One way or another, we should soon learn how an important part of the core of the Debian Jessie release will look.

