Systemd on Debian: What do you think?

Why care about Systemd?

In the spring of 2014 Debian committee members decided to switch to systemd with the next release (8.0 Jessie). But systemd was not loved by all people. Debian is a very stability-oriented distribution, therefore this leads to many discussions in the Debian community. I’ve seen very angry posts regarding this in the last few weeks - but what do you think?

I’ve seen comments from Linux guys that don’t understand or maybe don’t care about some of systemd benefits e.g. “Faster starting”. But that is maybe not a point, mostly they are concerned about the new “huge monster”. Monster in a sense of taking too many responsibilities. Some argue it’s harder to maintain, debug, and understand. Other people counter - it’s just big in the codebase…

So it is big! and it takes a lot of responsibilities (includes dbus and glib). All of this results in huge footprint of libs and code in comparison to sysvinit. But is it just bad? Is it about Linux philosophy (One tool for a task) only? Not only, at least there is a fear of the new binary logging. Indeed that is one of the controversy changes.

But there must be something good about systemd… let’s see:

Systemd overview

First of all, systemd is more than yet another replacement for the UNIX System V. Systemd is a suite of software that provides fundamental building blocks for a Linux operating system. One of the main goals of the systemd project is the unification of basic Linux configurations and service behaviors across all Linux distributions. Systemd utilizes “new” kernel concepts like cgoups and provides a unified view on service management, system-wide logging, mounting, networks, and more.

On a system start different tasks have to be done: Create Sockets, set up hardware, mount HDD, starting services, and so on. In systemd such tasks are organized as units. And every unit has its own config file. But such config files are much shorter than init-scripts and they are declarative only(!). Name convention is used type is represented by the file ending.

Unit types

Info: Updated in 2018

• .service - Describes services.
• .socket describes a network or IPC socket, or a FIFO buffer uses for socket-based activation. These always have an associated .service file that will be started when activity is seen on the socket.
• .path unit defines a path that can be used for path-based activation
• .mount - a mount point on the system. These are named after the mount path, with slashes changed to dashes. Entries within /etc/fstab can have units created automatically
• .automount - a mount point that will be automatically mounted. must have a matching .mount unit.
• .device describes a device that has been designated as needing systemd management by udev or the sysfs filesystem. Not all devices will have .device files.
• .timer unit defines a timer similar to a cron job for delayed or scheduled activation.
• .swap unit describes swap on the system.
• .target units are containers for other services, like run-levels.
• .slice is associated with Linux CGroup nodes, allowing resources to be restricted or assigned to any processes associated with the slice. Units are placed in certain slices by default depending on their type. The name reflects its hierarchical position within the cgroup tree.
• .scope units are created automatically from information received from its bus interfaces. These are used to manage sets of system processes that are created externally.
• .snapshot unit is created automatically by the systemctl snapshot command. It allows you to reconstruct the current state of the system after making changes.

So this overview might give a better feeling of things that Systemd aims to cover.

Systemd the good parts

Let’s look on Debian Position Statement for Systemd

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.

Can we go with that? After I read a bit of the idea of systemd I can in general agree with that. Here is an excerpt of the architectural points:

• Systemd makes the boot process much simpler, entirely removing the need to specify dependencies in many cases thanks to D-Bus activation, socket activation, file/inotify activation, and udev integration.
• Systemd can handle the boot process from head to toe, without needing to use any of the existing shell scripts.
• Systemd is straightforward. The command-line interface is probably the best existing 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 shipped by upstream, or at least 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 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.
• 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.
• systemd assumes that all resources may appear and disappear at any time. It’s hotplug capably.
• We can know the state of the system: systemd keeps track of all daemons, and all processes that are started, and who owns what, and when something fails, etc.
• Also, using the (awesome) journal all syslog() entries and writes to stdout/stderr by all processes are captured by systemd.
• It’s modular: all of what is now rc.sysinit is split out into many independent services, each of which is well documented and easy to understand.
• It allows dbus/udev to go back to doing the task they are meant to do: both udev and dbus are currently (mis)-used to start daemons/long-running services on demand. In the case of dbus this is by design, but in the case of udev it is not. Either way, it is not what those daemons were built to do, so in keeping with the UNIX principle of one task per daemon, it is great that we can now let systemd (whose job it is to manage daemons) take this over. That is, udev and dbus can both signal systemd to start a certain daemon, and it will behave like if it was started in any other way (you have the logs, status etc). One problem that this solves is the inherent race condition in some daemons (I think bluetoothd was guilty of this at some point) allowing both to be started as soon as possible on boot (say by putting it in DAEMONS), and to be started on-demand by dbus. Systemd makes sure that both these things can happen, and if they do happen at the same time you will only end up with one instance of the daemon as expected.
• We can reduce the number of explicit ordering dependencies between daemons…
• A lot of security/sandboxing features
• Systemd service files can (and hopefully will!) be written and distributed upstream: rather than every distro writing their own rc script
• logging will finally deliver on what consolekit was supposed to do: we can now track user sessions and seats, assign permissions to resources on-the-fly etc.
• It’s fast!

So what do you think?