Systemd on Debian: What do you think?

Why care about Systemd?

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

If've seen comment from linux guys that don't understand or maybe don't care of some of systemd benefits e.g. "Faster starting". But that is maybe not a point, mostly they are concerned about new "huge monster". Monster in a sense of taking too much responsibilities. Some argue its harder to maintain, to debug and to 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 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 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 provide unified view on service management, system wide logging, mounting, networks and more.

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

Unit types

Updated 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 mountpoint 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 mountpoint 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 better feeling of things that Systemd aims to cover.

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 disapear at any time. It's hotplug capable.

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 being 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.