Managing processes with systemd

Get It Started

Article from Issue 184/2016
Author(s):

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

01 [Unit]
02 Description=MySQL 5.6 database server
03 After=syslog.target
04 After=network.target
05
06 [Service]
07 Type=simple
08 User=mysql
09 Group=mysql
10
11 # Execute pre and post scripts as root
12 PermissionsStartOnly=true
13
14 ExecStartPre=/usr/libexec/mysql-check-socket
15 ExecStartPre=/usr/libexec/mysql-prepare-db-dir %n
16 ExecStart=/usr/bin/mysqld_safe --basedir=/usr
17 ExecStartPost=/usr/libexec/mysql-wait-ready $MAINPID
18 ExecStartPost=/usr/libexec/mysql-check-upgrade
19
20 # Give a reasonable amount of time for the server to start up/shut down
21 TimeoutSec=300
22
23 # Place temp files in a secure directory, not /tmp
24 PrivateTmp=true
25
26 [Install]
27 WantedBy=multi-user.target

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)

01 jcb@localhost:~$ systemctl
02 [...]
03 session-1.scope            loaded active running   Session 1 of user jcb
04 abrt-ccpp.service          loaded active exited    Install ABRT coredump hook
05 abrt-oops.service          loaded active running   ABRT kernel log watcher
06 abrtd.service              loaded active running   ABRT Automated Bug Reportin
07 accounts-daemon.service    loaded active running   Accounts Service
08 alsa-state.service         loaded active running   Manage Sound Card State (re
09 atd.service                loaded active running   Job spooling tools
10 auditd.service             loaded active running   Security Auditing Service
11 avahi-daemon.service       loaded active running   Avahi mDNS/DNS-SD Stack
12 bluetooth.service          loaded active running   Bluetooth service
13 chronyd.service            loaded active running   NTP client/server
14 colord.service             loaded active running   Manage, Install and Generat
15 crond.service              loaded active running   Command Scheduler
16 cups.service               loaded active running   CUPS Printing Service

 

Listing 3

Status Query for a Service

01 jcb@localhost:~$ systemctl status mysqld.service
02 * mysqld.service - MySQL 5.6 database server
03    Loaded: loaded (/usr/lib/systemd/system/mysqld.service; enabled)
04    Active: active (running) since Do 2015-11-26 09:52:45 CET; 7h ago
05   Process: 1528 ExecStartPost=/usr/libexec/mysql-check-upgrade (code=exited, status=0/SUCCESS)
06   Process: 1000 ExecStartPost=/usr/libexec/mysql-wait-ready $MAINPID (code=exited, status=0/SUCCESS)
07   Process: 919 ExecStartPre=/usr/libexec/mysql-prepare-db-dir %n (code=exited, status=0/SUCCESS)
08   Process: 793 ExecStartPre=/usr/libexec/mysql-check-socket (code=exited, status=0/SUCCESS)
09  Main PID: 999 (mysqld_safe)
10    CGroup: /system.slice/mysqld.service
11            |- 999 /bin/sh /usr/bin/mysqld_safe --basedir=/usr
12            |_1309 /usr/libexec/mysqld --basedir=/usr --datadir=/var/lib/mysql...
13
14 Nov 26 09:52:44 localhost.localdomain mysqld_safe[999]: 151126 09:52:44 mysql...
15 Nov 26 09:52:44 localhost.localdomain mysqld_safe[999]: 151126 09:52:44 mysql...
16 Hint: Some lines were ellipsized, use -l to show in full.

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

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy Linux Magazine

SINGLE ISSUES
 
SUBSCRIPTIONS
 
TABLET & SMARTPHONE APPS
Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • Tutorials – Systemd

    Take control of the services running on your Linux machine

  • Professor Knopper's Lab – Removing systemd

    The systemd service manager has been widely adopted by many Linux distros, so why would you want to remove it? The professor reveals why and how.

  • Command Line: Systemd

    Wondering what all the fuss is about systemd? We explain the basic concepts and capabilities of the new system management suite – coming soon to a distro near you.

  • Packages in systemd

    You might need to tweak your Debian or Ubuntu packages to get them to work with systemd.

  • systemd-networkd

    The new networkd component of the systemd project supports basic network configuration. Despite its early stage of development, one thing is clear: This is a daemon with brains.

comments powered by Disqus

Direct Download

Read full article as PDF:

Price $2.95

News

njobs Europe
What:
Where:
Country:
Njobs Netherlands Njobs Deutschland Njobs United Kingdom Njobs Italia Njobs France Njobs Espana Njobs Poland
Njobs Austria Njobs Denmark Njobs Belgium Njobs Czech Republic Njobs Mexico Njobs India Njobs Colombia