Differences between revisions 8 and 9
Revision 8 as of 2013-10-29 02:20:18
Size: 5750
Editor: ?JossMouette
Comment:
Revision 9 as of 2013-10-29 02:35:52
Size: 5788
Editor: ?JossMouette
Comment:
Deletions are marked like this. Additions are marked like this.
Line 12: Line 12:
 * Systemd is not just init. It unifies, in less 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 to remove a lot of cruft.  * Systemd is not just init. It unifies, in less 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 to remove a lot of cruft, and to use less memory on the system.

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

Systemd is becoming the de facto standard init system for Linux. Fedora, OpenSuSE and Arch have already made the choice to use it, and it is getting excellent upstream support for a growing number of packages.

Pros

  • Systemd is straightforward. The command-line interface is probably the best ever encountered for service management. The unit file format is completely declarative, can be parsed using standard tools, and is a breeze to maintain.
  • 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.
  • Systemd makes the boot process much simpler, entirely removing some of the dependencies thanks to D-Bus activation and socket activation.
  • Systemd handles the boot process from head to toe, without needing to use any of the existing shell scripts.
  • Systemd is not just init. It unifies, in less 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 to remove a lot of cruft, and to use less memory on the system.
  • Systemd uses control groups to ensure that any service, regardless of its state, can be shut down properly.
  • Systemd brings full logging of everything related to services, including the early boot, all of this integrating with the existing rsyslog daemon.
  • Systemd’s virtual TTY management allows real multi-seat support.
  • Systemd is incredibly fast (1 second to boot). It was not designed with speed in mind, but doing things correctly avoids all the delays currently incurred by the boot process.
  • A growing number of useful D-Bus services are either provided by systemd or built on top of it. These services are not specific to systemd per se, but so far it is the only implementation.

  • Systemd is a lively project with quite a number of developers from various companies, including Red Hat, Samsung and Intel.
  • The transition plan is easy, since existing init scripts are treated as first-class services: scripts can depend (using LSB headers) on units, units can depend on scripts. More than 99% of init scripts can be used without a modification.

Cons

  • 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.
  • Some of the pieces (like cryptsetup integration) are not completely ready in Debian and need polishing.

Systemd vs. sysvinit/insserv

  • Sysvinit was never designed to cope with the dynamic/event-based architecture of the current Linux kernel.
  • Sysvinit/insserv has very few C code, but the real code size must take shell scripts into account. These scripts come in huge numbers, contain bugs and are hard to maintain.
  • Debugging an init script is a tedious task. It is much faster to write a working systemd unit file than to debug an existing System V init script.
  • Sysvinit is insufficient for desktops, mostly because of missing features such as the D-Bus interfaces. But the real problems arise on big server setups, where Debian is losing ground because of its antiquated init system. On these systems, you need fine service management, process monitoring, reliable dependencies, complex device setups and proper event handling.
  • The only reason why we still use sysvinit today is the cost of a migration.

Systemd vs. Upstart

  • Systemd was developed after upstart, and as such it learned a lot from its mistakes.
  • The job file syntax is specific to upstart.
  • Upstart’s feature coverage is not as complete or correct as systemd. For example, socket activation is believed to be incorrectly implemented due to design issues.
  • Many features of systemd can be emulated with upstart, but using shell scripts and/or external tools that make maintenance more complicated.
  • Upstart does not implement the D-Bus services that exist on top of systemd. For some of them, Ubuntu has patches, but it means diverging from upstream and using Ubuntu as our effective upstream (and not just for upstart).
  • Upstart’s copyright agreement dismisses it as software of choice for our core system. It may not be the only important piece of software in Debian with a CLA, but there is no reason to add more trouble to the existing CUPS mess we already have.
  • It is often argued that Upstart’s developers are less hostile to a port to kFreeBSD. This is not entirely true, and regardless, this port does not exist today. To be taken into consideration, it would require credible information that someone intends to do the (huge) porting work if Upstart is chosen as default init system.

Systemd vs. OpenRC

  • The primary selling point of OpenRC is that it is portable. Otherwise, it is merely a sysvinit on steroids. It still relies a lot on shell scripts, does not implement socket activation and any other recent features.
  • OpenRC does not provide the systemd D-Bus interfaces. Using it would require someone to write or adapt, and maintain, Debian-specific tools to provide these interfaces. Gentoo currently does not have any solution for that issue.

Position statement maintainers

  • ?JossMouette