Systemd units and their purpose
Which systemd unit types are available and what is their goal? In this article we cover them and show some useful commands related to these units.
Showing all available unit types
Let’s start by displaying some of the units that are available on your system.
systemctl list-unit-files
This will reveal types like:
- Automount
- Device
- Mount
- Path
- Scope
- Service
- Slice
- Snapshot
- Socket
- Target
- Timer
Retrieve basic information from a unit
Before we dive into all unit types, it is good to know a few commands upfront. These help to inspect or learn more about a unit.
- Receive help: systemctl help ssh.service
- Show the unit file: systemctl cat ssh.service
- Show all unit settings: systemctl show ssh.service
Unit types
.service
This is a very common unit and refers to a service that runs in the background. Typically these are daemons that perform the whole type the system is running. Another option is a script that is executed by a trigger, like a repeating task.
.timer
Another common unit is the timer. It’s a scheduler, similar to cronjobs. Usually a timer and service file are paired together. The timer does the scheduling and then triggers the service.
systemctl list-timers
.target
A state within the service manager. It groups services and performs synchronization during the boot process or when the state changes. A good example of this is services that require the network stack to be up and running, like nginx. The network target can only be started when the basic functionality of the system is active, like some devices. In other words, it is a chain of events.
To see the time-critical tasks during the boot, we can use the systemd-analyze tool.
# systemd-analyze critical-chain
The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.
graphical.target @19.498s
└─multi-user.target @19.498s
└─snapd.seeded.service @17.537s +1.874s
└─basic.target @17.467s
└─sockets.target @17.466s
└─snapd.socket @17.444s +15ms
└─sysinit.target @17.419s
└─cloud-init.service @16.952s +465ms
└─systemd-networkd-wait-online.service @3.048s +13.900s
└─systemd-networkd.service @3.010s +36ms
└─network-pre.target @3.009s
└─cloud-init-local.service @2.383s +625ms
└─systemd-remount-fs.service @445ms +62ms
└─systemd-journald.socket @380ms
└─-.mount @345ms
└─-.slice @345ms
If we want to see how specific targets are linked, we can also use systemctl list-dependencies that shows the relationship between different units.
# systemctl list-dependencies local-fs.target
local-fs.target
● ├─-.mount
● ├─boot.mount
○ ├─systemd-fsck-root.service
● └─systemd-remount-fs.service
To have the local-fs.target up and running, a set of mount and file system checks have to be performed. We can see that the ‘fsck’ service is not running, as that only gets triggered when it is actually needed. The other three units (two mount units, one service) are active.
.socket
A socket description for socket based activation. This is typically something like a network socket, file system FIFO file, or other forms of inter-process communication (IPC).
systemctl list-sockets
.device
Devices that demand systemd management, are stored in this unit type, like the initrd (ramdisk).
.mount
Defines a mount point on the system
.automount
Defines a mount point that will be mounted automatically.
systemctl list-automounts
.path
Defines a file or directory to monitor and take trigger a related service. This is for example great to monitor for changes and then initiate a related action.
systemctl list-paths
.swap
Define the swap space, which is used when there is not enough memory.
.snapshot
Dynamic snapshot of the systemd runtime state. This is not a file type like the others, but an autogenerated definition.
.slice
Defines cgroups, which are the Linux Control Groups. They restrict access to resources, such as memory and CPU.
.scope
These are created automatically and are used to manage sets of systemd processes, such as a user sesion.
