Systemd as central control for the Linux system

More than init

Systemd is short for system daemon, that is, a background process that provides services for the system. The init process was at the beginning of the development and still gets most of the attention. Other components such as logind and the journal, however, are up there as well.

Systemd's init process is based on a slim PID-1 service that does only the bare minimum. Thanks to parallel processing, the computer's startup and shutdown runs much faster. It's based on a technology that Apple developed for launchd: socket activation.

Socket activation allows all services to start concurrently. The process also got simpler because developers and administrators no longer need to be aware of which service starts at which point during bootup with which dependencies. The trick is that systemd itself creates the communication sockets with the services to be started and buffers the data until the service is running and accepts it. The SysVinit concept rather forces dependent services to wait for each other, because the init system doesn't store any data itself.

Because all services start concurrently, systemd contributes greatly to simplifying the structure of the service files. These replace the SysVinit shell scripts that often went wild. Figures 2 and 3 show the differences based on the Kexec [8] example.

Figure 2: SysVinit: The Kexec startup script elicits constructs at various places where the purpose isn't readily apparent.

Figure 3: Systemd: The Kexec service file needs only a few lines whose function is clearer based on the variable names.

Systemd organizes all tasks pending at startup – such as readying the hardware, mounting the filesystem and starting the services – in units. The service files of the various units have their own filename extensions, which give a clue as to their functions.

Files with the .mount extension take care of mounting and unmounting the filesystems; those with the .service extension handle the background services. These units are stored uniformly in /lib/systemd/system . For a modification, copy the files in question manually to /etc/systemd/system/ and edit them as needed; the system automatically uses them from then on.

An important decision in designing systemd that contributed to its being used only in Linux was the integration of cgroups [9]. These control groups allow allocating and limiting kernel resources, such as CPU time, data throughput, and process group memory usage.

Systemd therefore provided new unit types as of version 205, including scope units and slice units. The former collect the system services or applications and all their dependencies into cgroups and manage them. The slice units provide the units with the required resources.

In the long term, the developers want to hand over the use and control of the cgroups completely to the daemon. In this way, systemd would become a new intermediate layer between the kernel and applications. Poettering himself sees it as a "glue." In any case, the structure thereby acquires some complexity (Figure 4).

Figure 4: The different layers of the systemd infrastructure make it difficult to consider it a simple service.

Journal

Unlike SysVinit, systemd logs the boot messages right from the beginning. Thus, screenshots of the boot process captured by smartphone for support forums become a thing of the past. Systemd instead creates a socket [10] for it at runtime, on which a minimal logging service runs and records the messages from the early boot phase. It later passes the socket to the regular protocol services and the message is journaled.

The journal replaces the long-used Syslog. In a first demonstration, it received much criticism because the journal deviated from the ongoing concept of storing text files in a flat hierarchy. Instead the files are stored as binary.

Apart from that, the journal has some hard-to-ignore advantages. Besides the aforementioned boot process logging, it allows for highly targeted queries. Thus, the command on the first line below shows the messages since the last system startup; whereas the second line shows what the web server put out in messages since midnight. In a blog entry, Poettering shows other more detailed queries [11].

$ journalctl -b
$ journalctl -u httpd --since=00:00 --until=9:30

As the name logind [12] suggests, the daemon takes care of user and session management and replaces the no longer developed ConsoleKit [13]. Thus, systemd begins to enter userspace, which again was not met without criticism.

In the end, Poettering wants to go still further by using the same mechanism for the processes starting Gnome or KDE and its applications. Apple's Mac OS X already does this. The first approaches can already be seen in Gnome 3, which has recently been pulling in parts of systemd by integrating logind.