Skip to main content Logo (IEC resistor symbol)logo

Quis custodiet ipsos custodes?
Home | About | All pages | RSS Feed | Gopher

systemd: Don't fear change

Published: 25-03-2015 | Author: Jonathan Roberts | Text only version of this article

Table of Contents

This article was originaly published in Linux Voice, issue 1, April 2014.This issue is now available under a Creative Commons BY-SA license. In anutshell: you can modify and share all content from the magazine (apart fromadverts), even for commercial purposes, providing you credit Linux Voice as theoriginal source, and retain the same license.

This remix is converted manually to Markdown and HTML for ease of archiving andcopy-pasting.

If you like this article, consider sponsoring me by trying out a Digital OceanVPS. With this link you'll get $100 credit for 60 days). (referral link)

Other converted Linux Voice articles can be found here.

The init replacement for RHEL 7 and SUSE Enterprise Linux 12.

systemd: Don't fear change

The arrival of a new Linux init system has been a long time coming. It was backin 2006 that Upstart was introduced to Ubuntu, and around the same time thatFedora and others also started experimenting with new init systems.

The reasons then are much the same as the reasons now - sysvinit is old anddoesn't do everything a modern distribution needs it to. More specifically:

Systemd fixes these problems and introduces a number of new features that makethe case for it even more compelling. Rather than explaining in great detail howsystemd works or how it fixes these problems (there's plenty of information onthat in, we're going to take alook at a few key features of systemd that might make sysadmins look forward tosystemd, rather than dread having to learn a new tool.

Configuration file format

As mentioned above, in sysvinit systems, configuration of services was complexand error-prone. They were usually configured through a combination of arcaneBash scripts in /etc/init.d and some environmental settings in/etc/sysconfig or /etc/defaults. These init scripts often did awful amountsof work, such as echoing service status to the console and managing lock files,which were repeated in almost every init script.

Systemd removes the need for much of the complexity in these init scripts byhandling service status echoes and suchlike itself. This means it can switchcomplex procedural Bash code for a clear, declarative configuration file. Forexample, here's the configuration for the syslog service on my Fedora system:

[Unit]Description=System Logging Service[Service]EnvironmentFile=-/etc/sysconfig/rsyslogExecStart=/sbin/rsyslogd -n $SYSLOGD_OPTIONSSockets=syslog.socketStandardOutput=null[Install]WantedBy=multi-user.targetAlias=syslog.service

All of the configuration options available in these files are extremely welldocumented (systemd as a whole has some of the best docs around) - see mansystemd.unit or man systemd.service for details.

What's more, if you had to modify a sysvinit file, you'd have to be careful whenit came to package upgrades etc that your changes wouldn't get overwritten. Withsystemd, unit files get packaged into /usr/lib/systemd/system, but if you wantto replace the default with your own, you can put them in /etc/systemd/systemand whatever is there will take precedence over the defaults.

You can even include other unit configuration files in yours, so you can easilyextend the default configuration:

include /usr/lib/systemd/system/nfs-secure.service#extra conf goes here

Resource controls

Why would you want to extend a service configuration like that? Well, systemdlaunches all processes inside their own cgroup (and all processes spawned fromthis end up in the same cgroup - this is also useful as it stops double forkingprocesses from orphaning themselves), so you can take advantage of this to usecgroups to limit the resources that each process (and its child processes) canconsume.

Systemd not only makes this possible by the way it spawns processes, but it alsomakes it easy by exposing many of the most common bits of functionality inconfiguration directives. For instance, you could limit the amount of CPU aprocess gets by dropping in a new unit configuration file to/etc/systemd/system and adding:


By default, systemd gives all processes (well, cgroups), an equal share of theprocessor (1024). By setting CpuShares to 200, you're restricting this processto about 20% of CPU time. What's more, this isn't applied just to the parentprocess but to all child processes. So if you have Apache running with manyhundreds of spawned CGI processes, this would restrict all of those processes toabout 20% of CPU time.

With the configuration file in place, you'd just need to tell systemd to reloadit, with systemctl daemon-reload, and then restart the service, withsystemctl restart httpd.service, for example.

You can also set memory limits (MemoryLimit) and IO limits (BlockIOWeight).See man systemd.resource-control for further details. There are also anynumber of security settings that can be put in the configuration files likethis.

For example, you can restrict a service from accessing a particular device, makeindividual directory trees inaccessible or read-only, create a private /tmpdirectory for a service or even stop a service, and all its child processes,from accessing the network.

In the example below, we've configured a service to have a private /tmpdirectory. See how simple it is:



Another aspect of systemd is that it collects all output from processes itstarts - whether that's through syslog() calls, messages emitted to STDOUTor STDERR, initial RAM disk or kernel messages. It does this through one ofits components, journald.

To see the contents of the logs, you can just type journalctl as root andyou'll get the results displayed, just as if you were looking at the contents of/var/log/messages or similar. This default view gives you some simpleimprovements over the traditional techniques, however. Error and higher prioritymessages are in red, notice and warning are bold, timestamps are in your localtimezone.

These are fairly cosmetic improvements. What sets journald apart is that thelogs are kept on disk in a binary format, which means that the journal entriescan be indexed on all fields, making them quick to search and easy to filter.For example:

journalctl PRIORITY=7 -since=yesterday

Will show all messages of debug priority received by the journal sinceyesterday. If you tried to do this with standard syslog messages or the like,you'd have to concoct your own grep or awk command, or hook it in to asystem like Logstash or Splunk.

There are loads of fields on which you can filter that come direct from themessages themselves, as well as a lot of metadata that the journal inputs in toeach log message itself, including SELinux context, hostname, transport etc.

To see the full details, you can read man systemd.journal-fields.

Journalctl even features tab completion of possible field names, so you can geta quick look too by typing

journalctl <tab><tab>.

There are many other great features in systemd that, if you take the time tolook around, will make your life as a sysadmin better.

We hope this article has at least given you the motivation to take a closerlook.

Tags: articles, centos, init, linux-voice, linux-voice-issue-1-2014, systemd, upstart