Re-evaluating systemd

Debian's General Resolution

By

After five years of use, Debian re-examines systemd support via a general resolution.

Few pieces of Linux software have been as controversial as systemd. All the same, by 2015, systemd had become part of all major distributions. However, in the last months of 2019, Debian re-examined systemd, leading to a general resolution about whether to support systemd or to include support for init and similar alternative services. In contrast to the original controversy, Debian's discussion focused on standard practices. In revisiting philosophical considerations, the discussion served as a re-evaluation of systemd after developers had time to become accustomed to working with systemd.

First developed by Lennart Poettering and Kay Sievers of Red Hat, systemd began as a replacement for init, the first process started during bootup. However, it quickly developed into an overall manager for system resources and services, acting as an intermediary between applications and the kernel and providing a common administrative utility for major distributions. Objections to systemd ranged from the claim that it was overly complex, that is was contrary to the Unix tradition of tinkering, to the conspiracy theory that systemd was part of Red Hat’s long range plans to seize control of Linux. In the years since, most developers and users grew to accept systemd, but the objections have never wholly gone away. DistroWatch’s search function reveals that 98 of 277 active distributions are built without systemd, a figure that indicates that a significant minority resistance continues to this day.

According to a posting by Debian Project Leader Sam Hartman, the reconsideration of systemd was brought about by the proposal to include a fork in Debian elogind of the systemd-logind daemon that provides support for systemd’s D-Bus-based login system, but runs without the whole of systemd. This setup opened the possibility of offering Debian builds with alternatives like init and SysVinit. With no consensus among elogind developers emerging after a lengthy discussion, Hartman concluded, “we’ve reached a point where in order to respect the people trying to get the work done, we need to figure out where we are as a project. We can either decide that this is work we want to facilitate, or work that we as a project decide is not important.” Although Hartman did not say, one reason for revisiting the issue was that in 2014 Debian specifically declined to take an official position on init alternatives.

The Debian mechanism for such issues is a general resolution. General resolutions are a key element in the project's management. Any Debian developer can propose a resolution; if seconded by five others, then the resolution may go to vote. Typically, a resolution argues for a course of action, and other resolutions offering other solutions are added to the ballot. Resolutions may concern how Debian is run or technical decisions. For instance, past general resolutions have been about topics varying from how to handle sourceless firmware, whether the GNU Free Documentation License qualifies as a free license, and even whether the Debian project leader should be impeached. Some proposals might be declared redundant, either by the proposers or by Debian officials, All this activity takes place on the debian-vote@lists.debian.org mailing list, with a gradual refinement of resolutions and proposals. Voters use their public encryption keys as proof of identity when they vote and generally can vote over several weeks.

The final vote is tallied by a Condorcet method, in which each proposal is compared against every other one until only one remains -- a system that is often said to be one of the fairest in the world. Any resolution that does not reach a quorum of eligible voters is dropped automatically.

For the systemd resolution, these proposals made the ballot:

  • Focus on systemd
  • Support systemd, but support exploring other alternatives
  • Support portability without blocking progress
  • Support non-systemd without blocking progress
  • Support portability and multiple implementations
  • Support for multiple init systems is important
  • Support for multiple init systems is required

These proposals cover a wide arrange of options: focusing only on systemd, making it easy to use other init systems (portability), and supporting multiple init systems to various degrees. In particular, “exploring,” “without blocking progress,” and “is important” are much vaguer and likely less meaningful than “is required.” “Progress,” of course, refers to working towards the next Debian official release and integrating contributed packages into the distribution.

Arguments and Discussions

Without exaggeration, the full arguments for each of these positions would make a small book, so only a few main arguments can be mentioned here. Proposing that multiple init systems be required, Guillem Jover suggested that any other position would be too rigid for an organization that, after all, consists largely of volunteers. He argued that the only sane position would be to decide on software on a case-by-case position, and universally accepted technical polices “can never be quantified and listed in a generic and universal way.”

In contrast, taking the position that non-systemd inits should be supported only without impeding progress, Debian old-timer Ian Jackson considered some of consequences of this proposal. Although Jackson suggested that not supporting non-systemd inits is a bug, he added that “it is not a release-critical bug,” presumably because it would not prevent a system from booting. Yet, as a result, “it may be possible to install software that will not work, or not work properly, because of an undeclared dependency on systemd.” Jackson also noted that init scripts would be an “added burden” for package maintainers. However, he could only hope that solutions to these potential problems might be found, which made this proposal seem like wishful thinking.

At the opposite extreme, former Debian Project Leader Martin Michlmayr proposed focusing on systemd. Michlmayr wrote:

It is important to recognize that the Linux ecosystem has widely adopted systemd and that the level of integration of systemd technologies in Linux systems will increase in time.… Integrating systemd more deeply into Debian will lead to a more integrated and tested system, improve standardization of Linux systems, and bring many new technologies to our users. Packages can rely upon, and are encouraged to make full use of, functionality provided by systemd. Solutions based on systemd technologies will allow for more cross-distribution cooperation.”

Although Michlmayr suggested that other init systems could be included in Debian, he concluded that systemd should be the only one officially supported.

Sam Hartman offered a less extreme position, writing that while systemd might be “the preferred configuration,” Debian has always had a tradition of offering alternatives, although “those interested in exploring such alternatives need to provide the necessary development and packaging resources.”

Hartman also said that “packages may include support for alternate init systems besides systemd and may include alternatives for any systemd-specific interfaces they use. Maintainers use their normal procedures for deciding which patches to include.”

In his role as Debian project leader, Hartman also offered a lesser version of this position -- issuing a statement that support for multiple init systems is merely important.

Resolution Results

The general resolution received 552 votes. The proposal to focus on systemd while exploring other alternatives had more votes than any other proposal and was immediately declared the winner (Figure 1). By contrast, requiring support for multiple init systems did not make quorum and was dropped.

Figure 1: The matrix showing how each resolution fared: Blue indicates the winning proposal; pink shows resolutions whose votes did not make quorum. Image: Debian.org

Whether this conclusion provided the clarity Hartman hoped to find is uncertain, since voting for it seems to mean supporting the chaos that sparked the vote in the first place. Still, it is a vote to recognize the diversity of init choices, which at least allows package maintainers to make plans accordingly.

What is interesting in this discussion is how the issue of systemd has shifted in the last five years. Notably, the resolution contained no proposal to eliminate systemd; it is now recognized that many people, particularly administrators, have grown to appreciate its power. Neither was there any reference to the Unix way of doing things that systemd might allegedly abandon. Instead, the focus was on practical issues, such as what choice might best suit Debian’s position as the source for dozens of derivatives and what burden a decision might place on package maintainers. This focus was the same in all the resolutions.

Whether any other distribution might re-evaluate systemd five years later is uncertain. Perhaps only such a famously diverse distribution like Debian would even even consider doing so. Ubuntu, for example, tends not to poll contributors about technical directions. Neither does Fedora. But considering the lingering controversies, perhaps Debian’s re-evaluation should be copied by other distros -- if only to confirm that systemd is here to stay.

Related content

  • Debian Tech Committee Votes for systemd

    Debian project puts init out to pasture and says no to Ubuntu's Upstart.

  • Devuan

    Devuan, with its promise of Init Freedom, provides users an alternative to systemd as an init process.

  • Packages in systemd

    You might need to tweak your Debian or Ubuntu packages to get them to work with systemd.

  • Debian Gets Forked

    Legendary Uber-distro splits over the systemd controversy.

  • Welcome

    The world is left to wonder if the recent news of a Debian fork is an important event or a minor historical footnote. Either way, it seems like a good story, reminiscent of the Linux stories of the past, when the community really looked and behaved like a collection of individuals rather than a corporate fan club.

comments powered by Disqus
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters

Support Our Work

Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.

Learn More

News