systemd
Once the boot process has completed and the bootloader has located the kernel and injected it into memory the first user space program runs: init
(for initialisation). init
is a daemon process that continues running until shutdown and is responsible for starting all the processes that are prerequisites for user space. For example: network connections, disk access, user logins etc. init
is the parent of all processes: PID1. Whilst it does a lot of its work in quick succession at boot time it is not limited to the this stage of the lifescycle but runs continuously in reponse to new user events.
On Linux systems systemd
is used to implement init
and therefore systemd
will always be listed as PID1.
systemd
is directly accessible from user space and provides a straightforward way to enable/disable, start/stop system level processes
systemd
can track individual service daemons after they start, and group together multiple processes associated with a service, giving you more power and insight into exactly what is running on the system How Linux Works: Third Edition, Brian Ward 2021
How systemd works
Goal-directed units
systemd
works on the basis of goals. Each goal is system task defined as a unit. A unit contains instructions and a specification of dependencies to other units.
When activating a unit, systemd
first activates the dependencies and then moves onto the details of the unit itself. init
as implemented by systemd
does not follow a rigid sequence every time, initialising units in the same sequence and waiting for one to complete before starting another. Instead it activates units whenever they are ready. This, its parallelized nature, is one of the main advantages over previous programs that managed the init
sequence on Linux (such as for example System V);
Unit types
Units are organised into unit types. The main types that run at boot time are as follows:
- service units (
.service
)- control service daemons
- socket units (
.socket
)- handle incoming network connection request locations
- device units (
.device
)- disks and other devices
- mount units (
.mount
)- handle the attachment of filesystems to the system
- target units
- control other units by organising them into groups
For example, at boot, a target unit called default.target
groups together a number of service and mount units as dependencies. These then run in a graph-like dependency structure where a unit that comes late in the boot process can depend on several previous units making earlier branches of a dependency tree join back together.
systemd configuration files
Units are managed via systemd
configuration files.
Configuration file locations
System level systemd
config files are located in the system unit directory at /usr/lib/systemd/system
. You shouldn’t change or manipulate these files or attempt to add new config files here since they will be overwritten by the system.
systemd
global unit files
Local definitions that relate to the specific user and where the user herself can define units are located in the system configuration directory: /etc/systemd/system
.
systemd
local unit files, specific to the currently logged-in user
Example files
Below is the systemd service file for the creation of UUIDs:
[Unit]
Description=Daemon for generating UUIDs
Documentation=man:uuidd(8)
Requires=uuidd.socket
[Service]
ExecStart=/usr/sbin/uuidd --socket-activation
Restart=no
User=uuidd
Group=uuidd
ProtectSystem=strict
ProtectHome=yes
PrivateDevices=yes
PrivateUsers=yes
ProtectKernelTunables=yes
ProtectKernelModules=yes
ProtectControlGroups=yes
MemoryDenyWriteExecute=yes
ReadWritePaths=/var/lib/libuuid/
SystemCallFilter=@default @file-system @basic-io @system-service @signal @io-event @network-io
[Install]
Also=uuidd.socket
- The
Unit
section provides metadata about the unit including whichsystemd
dependencies it has Service
constitutes the main specification for the unitInstall
is the call to set the dependencies running before theService
functions are accessible.
systemd operations: systemctl
The systemctl
command is the chief way of interacting with systemd
. You use it to activate and deactivate services, list their status, reload the configuration and so.
View the dependency graph
systemctl status
by itself will print a long list of units grouped by their dependency relations. It will also provide some metadata about the current systemd boot context.
Viewing active units
Below I have listed the running units pertaining to bluetooth:
$ systemctl list-units | grep bluetooth
sys-devices-pci0000:00-0000:00:14.0-usb3-3\x2d10-3\x2d10:1.0-bluetooth-hci0-hci0:3585.device loaded active plugged /sys/devices/pci0000:00/0000:00:14.0/usb3/3-10/3-10:1.0/bluetooth/hci0/hci0:3585
sys-devices-pci0000:00-0000:00:14.0-usb3-3\x2d10-3\x2d10:1.0-bluetooth-hci0.device loaded active plugged /sys/devices/pci0000:00/0000:00:14.0/usb3/3-10/3-10:1.0/bluetooth/hci0
sys-subsystem-bluetooth-devices-hci0.device loaded active plugged /sys/subsystem/bluetooth/devices/hci0
sys-subsystem-bluetooth-devices-hci0:3585.device loaded active plugged /sys/subsystem/bluetooth/devices/hci0:3585
bluetooth.service loaded active running Bluetooth service
bluetooth.target loaded active active Bluetooth Support
List jobs
Requests to activate, reactivate and restart units are called jobs in systemd
. They can be thought of as unit state changes. Current jobs can be listed with systemctl list-jobs
.
This will most likely return No jobs running
if the computer has been running for a while. Most jobs execute at boot.
Enable/disable, start/stop units
If a unit has dependencies it is necessary to enable it before starting it. This installs the dependencies.
systemctl enable mongodb.service
Created symlink /etc/systemd/system/multi-user.target.wants/mongodb.service → /usr/lib/systemd/system/mongodb.service.
Then we can start:
systemctl start mongodb.service
To stop the service:
systemctl stop mongodb.service
After this we should disable it, in order to remove any symbolic links it has created on the system as part of the install process:
systemctl disable mongodb.service
Removed "/etc/systemd/system/multi-user.target.wants/mongodb.service".