This page documents the position statement of those who think that Debian should adopt systemd as the default init system. Before editing this page, please see the instructions on how debates work. If you are not the maintainer of a position statement, and have a suggestion or change to make, please contact the maintainers.

Systemd position statement

Executive summary

Systemd is becoming the de facto standard init system for Linux. It replaces the venerable SysV init with a clean and efficient design, and brings a stream of new functionality that makes the life of users, administrators and packagers easier. It is better than existing alternatives for all of Debian’s current use cases:

Systemd represents a leap in terms of functionality, one that is comparable to Debian’s existing improvements over other operating systems. People are starting to expect this functionality when running Linux, and missing it could, in the long term, make Debian lose its purpose.

Why Debian should default to systemd

Fedora, OpenSuSE, Arch and Mageia have already made the choice to use systemd, and it is getting excellent upstream support for a growing number of packages.

Architecture

Systemd is well designed. It was conceived from the top, not just to fix bugs, but to be a correct implementation for the base system services.

Functionality

Systemd is not just init. It unifies, in fewer lines of code, everything that is related to starting services and managing session groups: user login, cron jobs, network services (inetd), virtual TTY management… Having a single system to handle all of that allows us to remove a lot of cruft, and to use less memory on the system.

Community

Systemd is a lively project with dozens of developers from various companies, including Red Hat, Samsung and Intel. It integrates contributions from even more individual contributors: to this date, 438 authors, with 63 having at least 10 commits. It can also be noted that two of the Debian maintainers have commit permissions.

Limitations to take into account

Portability

Systemd is not portable. This is a choice which was made, not without reasons, by the developers. If systemd is chosen for Linux (which we recommend), something else will have to be done for kFreeBSD.

Compatibility

Although systemd has better SysV compatibility compared to upstart, there are some documented incompatibilities. They only affect a handful of packages in the whole Debian archive, but it is worth taking into account.

Comparison with other init systems

sysvinit + insserv

Sysvinit was never designed to cope with the dynamic/event-based architecture of the current Linux kernel. The only reason why we still use it today is the cost of a migration.

Upstart

Upstart was a huge improvement over sysvinit, and Debian should have switched to it years ago. Now that systemd is available and well-tested, however, it cannot sustain the comparison. Upstart suffers from an improper design which replaces dependencies by purely event-driven actions, and its process tracking is implemented using the wrong tool (ptrace). It would be hard work to provide all the features systemd integrates on top of upstart, and its community, limited in size by Canonical’s policy, seems neither willing nor able to develop them.

Architecture

Maybe as a consequence of these design limitations, and despite being used in two LTS releases, Ubuntu did little work to convert existing SysV init scripts. Most daemons are still started with the SysV init script. By switching to upstart, we would still have to write most job files, not even knowing whether we can replace all of our legacy SysV scripts.

Functionality

Most of the new functionality brought in with systemd (and described earlier) is not available when using upstart.

Community

Sysvinit + OpenRC

OpenRC brings improvements to sysvinit while remaining compatible and portable, which are its primary selling points. However, it remains merely a sysvinit on steroids. It still relies a lot on shell scripts, is not event-based, does not implement socket activation, does not integrate with D-Bus, nor implements most of the other features we are now expecting from a modern init system.

Rebuttals

From the upstart statement

Overall, we agree strongly with the upstart proponents on the idea that the choice for Debian’s init system should be made mostly on technical merit. It is clear to us that systemd is overwhelmingly better than any existing alternative anywhere the technical architecture is involved.

From the sysvinit statement

Various other sources

The OpenRC statement has removed its systemd criticism, only keeping the vague “problems with Systemd have been debated a lot” statement. Since there is a lot of this criticism being spread by OpenRC or sysvinit advocates, it is still worth commenting on some incorrect, although widespread, beliefs.

Overall, many of the arguments of those who don’t want to migrate away from sysvinit (with or without OpenRC) boil down to rumors or irrelevant political stances, while the decision to choose a default init system should be based on technical facts and the shape of the community.

Questions from the CTTE

Relevant documentation

Position statement maintainers