LPIC-1: Systemd Beyond Services

In today’s post, we review some topics related to systemd that go beyond starting and stopping services. These topics were added to LPIC-1 in version 5.0.

Objective 101.3 already covered systemd in version 4.0. The focus of this objective is managing service units. A service unit controls the start and stop of a program. The units are defined in files ending in .service which reside in /usr/lib/systemd/system/, /run/systemd/system/ or /etc/systemd/system/. It is possible to override specific parameters or even whole unit files by creating directories and files in /etc/systemd/system/. Take a look at Justin Ellingwood’s blog post on Understanding Systemd Units and Unit Files to recap the structure of unit files.

When booting, target units specify which service units shall be run. After the system startup, systemctl provides various subcommands to manage units, such as start, stop, status, enable, disable, mask, unmask or edit. Review the manpage systemctl(1) and make sure you’re confident in using systemctl’s most important subcommands.

Over time, systemd became able to take care of an increasing number of crucial aspects of a Linux system. As more and more distributions use systemd for these tasks, the new version of LPIC-1 includes several of them. systemd provides its own logging infrastructure, the systemd journal. Systemd-journald attaches metadata to logging messages, so that it is possible, for example, to filter log messages produced by a specific systemd unit in a specific time frame. The command journalctl provides access to systemd journal. This command is covered in objectives 101.2 and 108.2.

As your system probably already runs systemd, get some confidence in using journalctl. Filter for messages from a specific service and get events from a specific time range. Run systemd-cat and filter the messages it produces. Find out where journald stores the journal, how long messages are retained and how to access them in case of an emergency, such as after booting into a live rescue system.

Justin Ellingwood wrote a great introduction, How To Use Journalctl to View and Manipulate Systemd Logs, which guides you through all these steps. The tutorial also introduces you to timedatectl which is covered in objective 108.1. You should take the chance to also review the concepts and configuration of rsyslog, which replaced syslog in objective 108.2. The rsyslog website contains several guides to get started.

Timer units in systemd have the ability to control service units. They are covered in objective 107.2. Similar to a cron job, a timer unit triggers a service unit at a specific point in time. Timer units, by default, control a service unit with the same name. man-db.timer, for example, starts man-db.service. Take a look at one of the timer units which exist on your systemd and review the systemd.timer(8) manpage for the various ways on how to specify the execution time. As a final exercise, try to create your own systemd service unit and trigger it with a systemd timer. TutorialDocs’ Systemd Timer Tutorial With An Automatic Mail Sending Example illustrates how to do this.

Socket units, as mentioned in objective 110.2, are another type of unit which controls service units. Similar to inetd, socket units open a socket in a file or at a port, wait for incoming connections and start the service for each connection. You will probably find some socket units which you can analyze on your system. Be aware that socket units can expose these services to remote clients, thereby exposing them to potential attackers.

systemd also handles file system mounts. While mount units can be used to trigger mounts, systemd also uses them to keep track of mounts. It automatically creates units when a new mount appears. Objective 104.3 covers awareness of mount units. You should investigate one of the mount units existing on your system and understand how they interact with mount and /etc/fstab.

Objective 109.2 provides three more examples of how many different problems systemd tries to address. The command hostnamectl is systemd’s way to adjust the hostname of the local computer. The manpage hostnamectl(1) provides an overview of the available subcommands. systemd-networkd and systemd-resolved are daemons that manage network configuration. LPIC-1 only expects you to be aware of them without any details of its configuration. Instead, LPIC-1 focuses on NetworkManager for persistent network configuration, which we review next week.

Previous post | Next post