Get It Started

The systemd service management daemon now comes with Red Hat, Debian, Ubuntu, SUSE, Mageia, Gentoo, Arch, and many other Linux alternatives. You might say systemd has finally arrived, but many users still have questions about what it is and why it is different. This article offers some tips on what you can do with systemd.

If you're running a Linux system with systemd onboard, systemd controls and organizes the entire boot process, starting processes and providing information on how those processes are faring.

Why did the world need another way to start processes in Linux? The fact is, the old System V init service that systemd is replacing is showing some serious signs of age. For instance, System V init can only line up the processes in a strictly sequential and rigid order, as opposed to starting different services simultaneously. Additionally, System V init uses shell scripts that are verbose, but still slow and difficult to read. These init scripts are not really suitable for coordinating processes that run in parallel.

Systemd addresses some of the problems posed by the previous init and adds some other interesting innovations.

New Boot Process

Systemd manage services and also devices and mount points. In systemd parlance, a managed object is known as a unit. The files used to that initialize and start such units at boot time are known as unit files. These unit files are the direct successors of init scripts. Admins will find the unit files in folders such as:

• /etc/systemd/system/*
• /run/systemd/system/*
• /usr/lib/systemd/system/*

Unit files are not executable but are configuration files in the style of Windows .ini files. A quick look at the unit file for starting a MySQL server shows how systemd works (Listing 1).

The [Unit] section contains a human-readable description of the service; the After variable specifies other services that need to start first. In this case, MySQL depends on the network and the syslog service already being up. You could use Before to define the mutual dependencies between services; in other words, you could start the service defined in the unit file before the designated service.

The [service] section sets the user account and group that the database server will use. Type determines the boot style: Simple means that the program specified below ExecStart starts the main process. The two MySQL scripts specified below ExecStartPre handle the preparatory work.

ExecStartPost calls scripts that need to run after the main program starts. The mysql-wait-ready script makes sure MySQL completes the cleanup that it normally performs at start-up time. This means that services that require MySQL do not start until the database is actually ready to accept connections.

Additionally, the unit file sets a timeout and assigns the database service to the multiuser target. This target is a special unit that basically assumes the role of the previous runlevel 3 in System V, which starts the system normally in multiuser mode.

More Security

Unit files support a slew of other parameters, including some options that provide an easy way for improving the security of your services.

The first of these parameters in the [Service] section is:

PrivateNetwork=yes

This setting completely isolates the service from any networks. The service then only sees a loopback device, and even that does not have a connection to the host's actual loopback device. Of course, this option is not very useful for network-based services. But, any service that can do without a network is completely safe from attack.

A word of caution: Sometimes you need a network, even if the need is not apparent at first glance. For instance, a service might perform most of its work locally but use LDAP to handle authentication. In that case, you need to be sure only users with a user ID below 1000 are authenticated; names need to resolve to UIDs locally through /etc/passwd for these accounts.

A second security feature in [Service] is:

PrivateTmp=yes

If this option is set, the service uses its own /tmp directory instead of the global /tmp, which protects the service against malicious Symlink and DoS attacks that tend to use /tmp. Unfortunately, this precaution will not work in some cases. Some services locate communication sockets in /tmp that will not work if they are in a private directory.

The next two options let you prevent services from writing to specific directories or even accessing them in any way:

ReadOnlyDirectories=/var
InaccessibleDirectories=/home

Linux provides a means for assigning the privileges traditionally associated with superuser. These privileges are known as capabilities, and you can see the list of all available capabilities by viewing the capabilities manpage:

man capabilities

Systemd additionally lets you assign specific capabilities to a service or withdraw those capabilities through settings in the unit file. For example, the following line in the [Service] section of the unit file:

CapabilityBoundingSet=CAP_CHOWN CAP_KILL

defines a whitelist of capabilities that the process must have.

Defining such a whitelist is not always easy. The other option is to take capabilities away from the service. If you prepend the capability with a tilde, this capability is explicitly taken away.

You can also use the unit file to limit the resources a service can access. The setrlimit() manpage lists all restrictable resources. For example, if you set the maximum size of a file (FSIZE) that the service is allowed to generate to  , as shown in the example below, the service cannot write the file anywhere. If you specify 1 as the maximum number of processes (NPROC) the service is allowed to spawn, the service cannot fork any other processes.

LimitNPROC=1
LimitFSIZE=0

You can limit other resources in a similar way.

Monitoring for Processes

After you system boots, you might want to know whether all the required services are actually running. The systemctl command provides an overview of service status. Systemctl lists all booted services with status information (Listing 2). If you only want to see the failed startups, try:

systemctl --state=failed

For a single service, you can view more detailed information with:

systemctl status mysqld.service

The output (Listing 3) shows the exit states of the pre- and post-scripts from the unit file, as well as additional information on the service status.

The status messages can be quite long on a case-by-case basis. Admins can thus use either the n line number parameter to limit the number of rows to output or the o file parameter to redirect everything to a file.