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, especially by conservative admins. 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 size, because systemd seemes to take too much responsibilities, and tends to be harder to maintain, to debug and to understand. Opposite site state it's just to 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:

Benefits of Systemd

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 are 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 (like .desktop or “ini” files) 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 dissapear at any time. it is 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 is 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 (At the moment i'm unsure about it)
  • 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.
  • It's fast

Systemd concepts

Different task has to be done on system start. Create Sockets, setup hardware, mount hdd, starting services and so on. In systemd such task are organized as units. And ever 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, following endings are possible:

  • .service - for services
  • .socket - opens sockets
  • .mount, .automount - for mounting
  • .path - watches paths and executes such units.
  • .target - are containers for other services, like run-levels.

Systemd unit configuration is based here: /etc/systemd/system/ if not present (/lib/systemd/system/ is taken). Some of units have no config files and will be generated by systemd. Systemd encapsulates every service in own Control Group. I look very interesting to me. It' add more control to the resource handling and remind's me on Docker.

So what do you think?