Managing processes with systemd
Get It Started

Sure, you've heard about systemd, which is rapidly replacing the old System V init system as the go-to service management daemon for the Linux world. But what can you do with systemd really? We'll show you some tricks for improving security, managing processes, and analyzing boot times with systemd.
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).
Listing 1
MySQL Unit File
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.
Listing 2
systemctl (excerpt)
Listing 3
Status Query for a Service
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.
Buy this article as PDF
(incl. VAT)
Buy Linux Magazine
Direct Download
Read full article as PDF:
Price $2.95
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters
Find SysAdmin Jobs
News
-
Kubuntu Focus Announces XE Gen 2 Linux Laptop
Another Kubuntu-based laptop has arrived to be your next ultra-portable powerhouse with a Linux heart.
-
MNT Seeks Financial Backing for New Seven-Inch Linux Laptop
MNT Pocket Reform is a tiny laptop that is modular, upgradable, recyclable, reusable, and ships with Debian Linux.
-
Ubuntu Flatpak Remix Adds Flatpak Support Preinstalled
If you're looking for a version of Ubuntu that includes Flatpak support out of the box, there's one clear option.
-
Gnome 44 Release Candidate Now Available
The Gnome 44 release candidate has officially arrived and adds a few changes into the mix.
-
Flathub Vying to Become the Standard Linux App Store
If the Flathub team has any say in the matter, their product will become the default tool for installing Linux apps in 2023.
-
Debian 12 to Ship with KDE Plasma 5.27
The Debian development team has shifted to the latest version of KDE for their testing branch.
-
Planet Computers Launches ARM-based Linux Desktop PCs
The firm that originally released a line of mobile keyboards has taken a different direction and has developed a new line of out-of-the-box mini Linux desktop computers.
-
Ubuntu No Longer Shipping with Flatpak
In a move that probably won’t come as a shock to many, Ubuntu and all of its official spins will no longer ship with Flatpak installed.
-
openSUSE Leap 15.5 Beta Now Available
The final version of the Leap 15 series of openSUSE is available for beta testing and offers only new software versions.
-
Linux Kernel 6.2 Released with New Hardware Support
Find out what's new in the most recent release from Linus Torvalds and the Linux kernel team.