systemd Is Not About "Système D"

A lot has been written about systemd, so it is a good time to explain what systemd will bring to your SUSE Linux Enterprise 12 system (you can already taste systemd for your self with openSUSE).

Currently, many shell scripts (called initscripts) are being run at the startup of your system to perform the proper initialisation and startup of the various components of the Linux operating system. This set of scripts, as well as the program taking care of ordering those scripts’ startup and shutdown, is usually named “SysVinit” (acronym for System V init).

In March 2010, Lennart Poettering announced systemd, a replacement for the sysvinit daemon and the initscripts with it, while keeping compatibility with sysvinit infrastructure.

For administrators, even when using /etc/init.d/skeleton as a basis, writing an initscript can be tricky and sometimes requires very good shell knowledge. On the other hand, systemd uses files (named unit files, in a format similar to .INI files), which are easy to read for both an human (no XML) and a computer perspective – and still extensible, if needed. Its syntax is well defined and documented (see man pages for systemd.unit / systemd.exec / systemd.mount / systemd.service / systemd.socket / systemd.target‚ etc.).

Another important feature of systemd helps with package installations. On a Linux system installed with packages, this is key when dealing with package upgrades and modifications that you might need to do on files provided by a package.

In the sysvinit initscript world, if you ever needed to modify a initscript, you would need to ensure your modifications are not lost when you apply a maintenance update or when you upgrade your system. With systemd, administrative modifications are kept in a different space than packages. All unit files are packaged in /usr/lib/systemd/system, but if you ever need to override a file there, you can just copy it to /etc/systemd/system and it will have precedence over the “package” version of the file.

Even better, to ensure you don’t have to maintain your copy (if the packaged version is modified by an update), you can either include another file in your modified copy with a syntax like:

include /usr/lib/systemd/system/foobar.service
#then you add your new lines

Or, with recent versions of systemd available in openSUSE 12.3, you can use drop-in files in a directory named after the file you want to “patch.” For instance, to modify /usr/lib/systemd/system/foobar.service, you just need to create
a directory called /etc/systemd/system/foobar.service.d/ and in that directory drop a file named “whatevermodification.conf” containing only the lines you want to add (or modify).

systemd allows the use of several Linux kernel features in unit files without any hassle. For instance, with systemd you can easily:

• Limit network access (thanks to namespace) by adding "PrivateNetwork=yes" to a unit file.
• Use a non shared /tmp directory with "PrivateTmp=yes"
• Limit access to some directories or make them read-only, thanks to "InaccessibleDirectories=/home" or "ReadOnlyDirectories=/var"
• Limit capabilities available to process:
  CapabilitiesBoundingSet=CAP_CHOWN CAP_KILL (list only accepted capabilities)
  CapabilitiesBoundingSet=~CAP_PTRACE (if you want to just prevent one capability)
• Ensure a service will be started by a specific user/group or with a specific root directory

  User= ; Group= ; RootDirectory=

• You can even restrict access to devices (with white or blacklist)

  DeviceAllow=/dev/null rw
  DeviceDeny=/dev/tty w

• Apply resources limitation (similar to what is possible with ulimit)

  LimitNPROC=1, LimitFSIZE=0...

Thanks to systemd, you can easily leverage control groups on any of your services. Control groups (often abbreviated as cgroup) are a kernel feature that enable grouping processes (and all their children) and configures them with a specialized behaviour (resource limitation, accounting, etc…).

On systemd, each service has its own separate cgroup (which helps you track which service started with which process, either by looking at its cgroup or using tools like systemd-cgls or systemd-cgtop). And you can then apply cgroups attributes to a service, like cpu shares, block I/O, memory limits, etc.

For instance, if you want to ensure one service isn’t taking more than 20% of CPU power (at the expense of other services), you can just add a drop-in file containing

[Service]
CpuShares=200

(Each service will get 1024 shares, so 20% of 1024 is approximately 200.)

Or you could also use MemoryLimit=1G to ensure one service (which can be a collection of several processes) cannot use more than 1 GB of memory.

Finally systemd features Journal, which acts as a central point to collect all output from services (syslog as well as error and standard output) to either forward them to syslog implementations (rsyslog, syslog-ng, etc.) or to store them on disk using its own format.

This documented binary format enables several features that are not doable (or hard to do) using a full-text format, such as indexed search, inline compression, storing binary data (like a coredump or a bootchart), or Forward Secure Sealing (learn how to detect if logs haven’t been tampered with).

These are just some of the many features systemd will bring to SUSE Linux Enterprise 12, making it an even more efficient operating system for the enterprise.