Differences between revisions 27 and 28
Revision 27 as of 2013-10-30 00:30:06
Size: 12400
Editor: ?JossMouette
Comment:
Revision 28 as of 2013-10-30 00:41:58
Size: 12446
Editor: ?JossMouette
Comment:
Deletions are marked like this. Additions are marked like this.
Line 54: Line 54:
 * 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.  * 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, is not event based, does not implement socket activation and most other recent features.
Line 59: Line 59:
 * The upstart page mentions that systemd is “hasty”. It is forgetting that several major releases of several distributions have already happened using systemd as default. It is no longer, by far, an experimental technology. Compatibility at upgrade time should not be a concern either, since the real outside interfaces (D-Bus, unit files, Debian configuration files) have always been stable. There will, most probably, be locked-in upgrades with udev from time to time, but it does not have any impact on the ability to upgrade systems.
 * The upstart page talks about systemd as “greedy”, as in it shouldn’t integrate all these features so closely to PID 1. First of all, more useful features are not a disease. Getting to the point: while it is true that a handful of trivial interfaces is not really related to systemd (and could be split out if needed), most of these features cannot be implemented without close integration to PID 1. It is not possible to split the system cgroups arbitrator from the process which starts services and sessions in cgroups. It is not possible to ensure the relation of a log to a service if you do not have awareness of how the service was launched. ''Et caetera''.
 * The upstart page mentions Debian should “not find itself at the mercy of other parties who wish to dictate design to us.” These words sound a bit ironical, coming from proponents of a system who is solely developed and maintained by Ubuntu, and which would make Debian depend on a single party for such a core package.
 * The sysvinit page mentions “traditional UNIX principles” which systemd would not adhere to. If you look at how traditional Unixes such as Solaris or BSD are architectured, they are very similar to systemd, actually: a large set of small utilities, each one with a defined purpose, but which are absolutely not interchangeable or replaceable.
 * The sysvinit page mentions systemd benefitting “mostly the GNOME desktop”, which is entirely untrue. While GNOME, and probably Xfce and KDE soon, use the interfaces implemented by systemd, they are not, by far, the primary beneficiaries of systemd. As the feature list shows, it is for server setups that systemd is the most useful.
 * The upstart statement mentions that systemd is “hasty”. It is forgetting that several major releases of several distributions have already happened using systemd as default. It is no longer, by far, an experimental technology. Compatibility at upgrade time should not be a concern either, since the real outside interfaces (D-Bus, unit files, Debian configuration files) have always been stable. There will, most probably, be locked-in upgrades with udev from time to time, but it does not have any impact on the ability to upgrade systems.
 * The upstart statement talks about systemd as “greedy”, as in it shouldn’t integrate all these features so closely to PID 1. First of all, more useful features are not a disease. Getting to the point: while it is true that a handful of trivial interfaces is not really related to systemd (and could be split out if needed), most of these features cannot be implemented without close integration to PID 1. It is not possible to split the system cgroups arbitrator from the process which starts services and sessions in cgroups. It is not possible to ensure the relation of a log to a service if you do not have awareness of how the service was launched. ''Et caetera''.
 * The upstart statement mentions Debian should “not find itself at the mercy of other parties who wish to dictate design to us.” These words sound a bit ironical, coming from proponents of a system who is solely developed and maintained by Ubuntu, and which would make Debian depend on a single party for such a core package.
 * The sysvinit statement mentions “traditional UNIX principles” which systemd would not adhere to. If you look at how traditional Unixes such as Solaris or BSD are architectured, they are very similar to systemd, actually: a large set of small utilities, each one with a defined purpose, but which are absolutely not interchangeable or replaceable.
 * The sysvinit statement mentions systemd benefitting “mostly the GNOME desktop”, which is entirely untrue. While GNOME, and probably Xfce and KDE soon, use the interfaces implemented by systemd, they are not, by far, the primary beneficiaries of systemd. As the feature list shows, it is for server setups that systemd is the most useful.

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, Arch and Mageia 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 unit files, unlike SysV scripts, can usually be shared with other distributions (already more than 1000 existing unit files in Fedora) without any changes, the Debian specifics being handled by systemd itself.
  • 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 extends the logging features of the system in many ways with journald, while remaining integrated with the existing rsyslog daemon. Logs are attributed to PID and service, they include the early boot (starting from initramfs). They can be quickly filtered and programatically accessed through an efficient interface.
  • Systemd’s virtual TTY management allows real multi-seat support, and revoking access to input devices on session switch.
  • 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.
  • Systemd can trivially add security settings to a service without any need to patch it: user/group change, chroot, private network, private /tmp, read-only access to parts of the tree, tcp wrappers, filtering system calls, ?NoNewPrivileges (kernel feature to avoid privilege changes), limiting effective capabilities, limiting whatever the kernel provides in an integrated manner (device bandwidth, CPU usage, memory usage, OOM settings, nice levels, timer slack, ulimits…)

  • Systemd ships a growing number of useful, unified command-line interfaces for system settings and control (timedatectl, bootctl, hostnamectl, loginctl, machinectl, kernel-install, localectl). In Debian, they use the existing configuration files without breaking compatibility.
  • In addition to command-line interfaces, Systemd provides a D-Bus API to control service management and access system settings, as well as bindings to do that from Python, node.js, php, lua, Qt… GNOME is relying on these services, and it is likely for KDE and Xfce to use pieces of it in the near future. They are not specific to systemd per se, but so far it is the only implementation.

  • Systemd can run without any configuration change in a virtual machine or a container. It will automatically skip services which need to.
  • Systemd is used inside the initramfs, which means the same code serves an additional purpose, and there's less stuff to maintain. It can also hand control back to the initramfs at shutdown, making it possible to cleanly unmantle even very complicated setups where the root fs lives on some complicated stacked setup.
  • Systemd is moving strongly in the direction of configuration-less system (i.e. “empty /etc/”). So /etc/fstab might be empty on a system with a GPT partition table, with partitions mounted in appropriate places based on their type id. This means that the configuration of the common one-machine-one-disk setup becomes even simpler.

  • Systemd ships top-level documentation for all tools and configuration files, as well as design documents and administration tutorials.
  • 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. It can also be noted that two of the Debian maintainers have commit permissions.
  • 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.
  • It is theoretically possible to port Systemd to Hurd or ?OpenSolaris, provided someone volunteers to maintain it a la portable OpenSSH, but kFreeBSD has no credible replacement for control groups.

  • 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.
  • Upstart job files are written using a specific syntax which is not purely descriptive and can include operands or shell scripts. Among other problems, this makes it impossible to parse the files with external tools.
  • Upstart’s feature coverage is not as complete or correct as systemd. For example, socket activation is believed to be incorrectly implemented. Worse, the use of ptrace is a fundamental design issue that prevents the use of upstart jobs for important daemons like avahi, apache or postfix.

  • Maybe as a consequence, 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.
  • Another consequence of upstart abusing ptrace(2) is the impossibility to attach gdb to processes run by the init system, or to run them in valgrind like systemd allows.
  • Many features of systemd can be emulated with upstart, but using shell scripts and/or external tools that make them less reliable and more complex to maintain.
  • 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. However, 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.
  • Upstart cannot reliably track a process and this can lead to difficult to handle bugs. Some jobs may be stuck in start/killed state because of this.

  • Systemd has a much larger and more active committer base than upstart.

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, is not event based, does not implement socket activation and most 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.
  • One of the primary improvements of OpenRC over sysvinit is the use of cgroups, but the functionality will not be available on kFreeBSD.

Rebuttals

  • The upstart statement mentions that systemd is “hasty”. It is forgetting that several major releases of several distributions have already happened using systemd as default. It is no longer, by far, an experimental technology. Compatibility at upgrade time should not be a concern either, since the real outside interfaces (D-Bus, unit files, Debian configuration files) have always been stable. There will, most probably, be locked-in upgrades with udev from time to time, but it does not have any impact on the ability to upgrade systems.
  • The upstart statement talks about systemd as “greedy”, as in it shouldn’t integrate all these features so closely to PID 1. First of all, more useful features are not a disease. Getting to the point: while it is true that a handful of trivial interfaces is not really related to systemd (and could be split out if needed), most of these features cannot be implemented without close integration to PID 1. It is not possible to split the system cgroups arbitrator from the process which starts services and sessions in cgroups. It is not possible to ensure the relation of a log to a service if you do not have awareness of how the service was launched. Et caetera.

  • The upstart statement mentions Debian should “not find itself at the mercy of other parties who wish to dictate design to us.” These words sound a bit ironical, coming from proponents of a system who is solely developed and maintained by Ubuntu, and which would make Debian depend on a single party for such a core package.
  • The sysvinit statement mentions “traditional UNIX principles” which systemd would not adhere to. If you look at how traditional Unixes such as Solaris or BSD are architectured, they are very similar to systemd, actually: a large set of small utilities, each one with a defined purpose, but which are absolutely not interchangeable or replaceable.
  • The sysvinit statement mentions systemd benefitting “mostly the GNOME desktop”, which is entirely untrue. While GNOME, and probably Xfce and KDE soon, use the interfaces implemented by systemd, they are not, by far, the primary beneficiaries of systemd. As the feature list shows, it is for server setups that systemd is the most useful.

Relevant documentation

Position statement maintainers

  • ?JossMouette