Systemd [1], the initially highly controversial system and process manager in the Linux community, is now considered established – the old SysVinit system has largely had its day. However, critics still gripe about the binary format of the logfiles, the fact that systemd sometimes uses DNS queries on Google's name servers, and the strong orientation toward the Gnome desktop.

Nonetheless, systemd also offers advantages compared with its predecessor. The fact that it starts processes in parallel significantly reduces the time required for booting the operating system, especially on multicore computers. And, the compiled program accelerates the process.

Systemd Basics

The processes managed by systemd are called units. They are formally reminiscent of traditional INI files, and they perform various tasks: They manage services, define mountpoints, take care of the swap memory, or create devices.

Service units that manage services are similar to the init scripts from SysVinit or Upstart. The function a unit performs is revealed by its file extension; for example, variations with .service take care of services, and units with .mount as the extension mount filesystems. Units with a .timer extension control repetitive tasks and are reminiscent of cronjobs, whereas .device units create device files.

The .socket and .target unit configuration files take up a special position: .socket activates a service, whereas .target groups multiple units and partially replaces the runlevels familiar from SysVinit.

Admins control the units on the command line with:

systemctl <Options> <Commands>

This, among other things, is used for editing the configuration files of the respective units, which are available in text format. To do so, enter:

systemctl edit --full <Unitname>

at the prompt. Journald also acts as a service unit of systemd that takes care of the log entries in the central journal. The command journalctl <option> offers insight into the logfile containing numerous parameters for partial queries.

Graphical Tools

Admins usually configure, control, and monitor systemd using the command line. But, as the init system continues to spread, there are also more and more graphical tools, and their range of functions vary significantly. If you need a solution to suit your individual needs, take a closer look at all the candidates before installation (Table 1).

Along with the software Cockpit [2] (developed by Red Hat), which partly has a similar functionality to Webmin [3] and is thus primarily used for server administration, several small projects now also manage systemd on single-user systems. However, they usually require a special desktop environment. These include the Systemd System Manager in the package systemd-gui or systemd-ui [4], although this is an interface based on the GTK+ toolkit.

Other options are Systemd Manager [5], with a GTK 3 interface, and Kcmsystemd [6], which is on the KDE desktop. A further development of this software is called Systemd-KCM [7]. The current version requires KDE Plasma 5 as a desktop environment and does not work with older versions of KDE. As of recently, the original KDE configuration module is called SystemdGenie [8] and exists as a standalone application. Besides this desktop-specific application, there are other applications – such as, Gnome Logs [9] – that only support part of systemd with Journald and thus are not fully fledged management tools.

The individual applications are also integrated differently in the desktop: Although the tools for GTK-based systems work largely as standalone applications, the KDE versions fit into the desktop's control center as individual modules except for the new SystemdGenie.

One advantage is that the users also have to configure the systemd components through a single interface and do not have to manage their system using multiple applications with partially different control concepts. However, the naming can cause confusion: For example, the Systemd System Manager [4] is hidden behind the package systemd-gui in Linux Mint and Ubuntu (systemd-ui in Debian) – and inexperienced users often confuse this with Systemd Manager [5].

Kcmsystemd

For the KDE desktop in version 4.x, Kcmsystemd [6] integrates seamlessly (the first three letters stand for KConfig modules) into the management tools of the work interface. If the user installs the package of the same name, he or she will encounter the Systemd starter in the System area of the Customize your desktop front end. Clicking here opens a list window with several horizontal tabs, which make it clear that Kcmsystemd itself is a comprehensive solution for managing systemd (Figure 1).

Figure 1: The Kcmsystemd graphical interface is clear but also has a number of control elements.

The start activates the Units tab in the left pane. It specifically lists all units and shows their current status. Only active units are preset. If you check the Show inactive option, you will also see inactive units. Because there are usually several hundred entries, a search box for tracing the desired unit is also a great help.

The list with units shows the Load state, Active state, the Unit state, and the name of the process for each entry. It also reveals whether the system has loaded and activated the respective unit and indicates the current status. Click on any process, and details appear below the list.

You can stop or restart individual units using the Stop and Restart buttons; however, this does not work for all entries. You cannot stop or restart device files, which help systemd to manage connected devices. With such units, the software grays out the corresponding control fields.

If the user passes over the individual units with the mouse, the dependencies of the unit from others appear in temporary pop-up windows. The admin thus immediately sees which other units are required in parallel (Requires:) or absolutely presupposes (After:), and which ones systemd wants to start in parallel regardless of other units (Wants:). Particularly with complex targets, this information helps solve problems with the init system (Figure 2).

Figure 2: A box (highlighted in blue) with the display of processes shows information about the interaction of multiple Kcmsystemd units.

Right-clicking on any process opens a context menu that – depending on the kind of unit – presents different options. If there are problems, the admin can use it to turn off certain services (Disable Unit). Regardless of the type of process, the admin can also edit the corresponding configuration files with the exception of the device units.

To do so, you need to click on the Edit Unit File option in the context menu and then be authenticated as an administrator. This opens the text editor KWrite with the corresponding configuration file for the selected unit, which can now be easily edited (Figure 3).

Figure 3: You can easily edit configuration files.

The admin then needs to restart the unit so that the modifications are valid. Cryptic startup scripts and the use of a shell interpreter are things of the past in systemd.

The tabs Systemd, Defaults, Journald, and Logind to the right of the Units tab are not dedicated to the configuration of individual processes and targets but rather deal with adapting systemd itself, including logging as well as registration and session management.

On the other hand, the admin can adjust the logging system Journald separately. Along with path specifications to the journal store and the size of the journals, the configuration options of the four tabs also include CPU-specific information. This is how the user can, for example, assign CPU resources in the Systemd tab in the Advanced Settings or perform certain hardware-dependent configurations (Figure 4). The session management Logind tab includes settings for system conditions such as for power management or virtual terminals.

Figure 4: Interested individuals can perform very fine adjustment of the protocol function using Kcmsystemd.

The admin can write the modifications to the /etc/systemd directory using the Apply button at the bottom right of the settings window. The software only initiates the write operation after authentication via a separate window.