systemd and systemctl

What systemd does

When Linux boots, the kernel starts one program, process 1, and that program starts everything else. On Ubuntu and most distributions, it’s systemd: a “system and service manager” that brings up the system, then starts and watches over the background programs that keep it running, the network, logging, printing, the login screen ¹. It also starts a separate user manager for each person logged in, for their own services ¹.

me@garden-laptop:~$ ps -p 1

shows it. Most of the time you won’t think about systemd; you’ll use it when something needs starting, stopping, or fixing.

Units

Everything systemd manages is a unit, described by a small text file. The type is the file’s ending ²:

• .service: a program to run and supervise, like ssh.service or cups.service (printing).
• .timer: a schedule that starts a service (lesson 3).
• .mount: a file system to mount (next module).
• .socket: a network or local connection that starts a service on demand.
• .target: a group of units reached together, like graphical.target for a desktop.

You can usually leave off .service: systemctl status ssh means ssh.service.

Checking on a service

systemctl status is the first command for any question about a service. The example in systemctl’s manual ³:

$ systemctl status bluetooth
● bluetooth.service - Bluetooth service
     Loaded: loaded (/usr/lib/systemd/system/bluetooth.service; enabled; preset: enabled)
     Active: active (running) since Wed 2017-01-04 13:54:04 EST; 1 weeks 0 days ago
       Docs: man:bluetoothd(8)
   Main PID: 930 (bluetoothd)
     Status: "Running"
      Tasks: 1
     Memory: 648.0K
        CPU: 435ms
     CGroup: /system.slice/bluetooth.service
             └─930 /usr/lib/bluetooth/bluetoothd

Jan 12 10:46:45 example.com bluetoothd[8900]: Not enough free handles to register service
Jan 12 10:46:45 example.com bluetoothd[8900]: Current Time Service could not be registered
Jan 12 10:46:45 example.com bluetoothd[8900]: gatt-time-server: Input/output error (5)

Reading it ³:

• The dot sums it up: green ● active, white ○ inactive, red × failed.
• Loaded: shows the unit file’s path and whether it’s enabled (starts at boot).
• Active: shows whether it’s running now, and since when.
• Main PID and CGroup show its processes; Memory and CPU what it’s using.
• The last lines are its most recent log messages, often the answer to “why isn’t this working?”

status doesn’t need sudo. It opens in a pager if the output is long; q quits.

Start, stop, enable, disable

Two separate questions: is it running now, and does it start at boot? ³

me@garden-laptop:~$ sudo systemctl stop cups
me@garden-laptop:~$ sudo systemctl start cups
me@garden-laptop:~$ sudo systemctl restart cups
me@garden-laptop:~$ sudo systemctl disable cups
me@garden-laptop:~$ sudo systemctl enable --now cups

• start, stop, restart act now. reload asks a running service to reread its own configuration, for services that support it.
• enable makes it start at boot, by creating links as the unit file’s [Install] section says; disable removes them ³.
• enable --now enables and starts in one go; disable --now disables and stops ³.
• mask goes further than disable: it makes the unit impossible to start at all, even by hand, until you unmask it. Use with care ³.

systemctl is-active cups and systemctl is-enabled cups answer the two questions with one word each, and exit 0 for yes, handy in scripts ³.

Finding problems

me@garden-laptop:~$ systemctl list-units --failed
me@garden-laptop:~$ systemctl list-units --type=service
me@garden-laptop:~$ systemctl list-unit-files --state=enabled

--failed is the quick health check: an empty list is good news. For any unit it lists, systemctl status name and the journal (next lesson) say why.

Unit files

Unit files live in a few places, and the first match wins ²:

• /usr/lib/systemd/system/: from installed packages. Don’t edit these; updates overwrite them.
• /etc/systemd/system/: yours. A file here overrides the package’s file of the same name.
• ~/.config/systemd/user/: your own user units.

systemctl cat ssh prints a unit’s file, plus any overrides ³. To change one setting without copying the whole file, sudo systemctl edit ssh opens an empty drop-in file in your editor; what you put there is added on top of the package’s file and survives updates ³. A unit file is a simple INI-style text file:

[Unit]
Description=What it is

[Service]
ExecStart=/usr/bin/the-program --options

[Install]
WantedBy=multi-user.target

After creating or changing unit files yourself, run sudo systemctl daemon-reload so systemd rereads them ³. (systemctl edit does that for you.) Don’t confuse it with reload, which is for a service’s own configuration.

System and user

Everything above is the system manager, so changes need sudo. Your user manager runs services for you alone, from ~/.config/systemd/user/, with no sudo: add --user to every command, as in systemctl --user status ^{4 1}. Lesson 3 uses it for a backup timer.

Power, and a slow boot

systemctl also shuts down and restarts:

me@garden-laptop:~$ systemctl reboot
me@garden-laptop:~$ systemctl poweroff
me@garden-laptop:~$ systemctl suspend

If startup feels slow, systemd-analyze prints how long the boot took, and systemd-analyze blame lists units by how long each took to start, slowest first. Treat it as a hint: a unit can look slow just because it was waiting for another ⁵.

Your turn

So

systemd is process 1: it boots the system and starts and supervises units, .service, .timer, .mount, .socket, and .target. systemctl status shows a unit’s state and recent log lines; start, stop, restart, and reload act now, while enable and disable decide what starts at boot (enable --now does both). list-units --failed finds trouble. Packages’ unit files are in /usr/lib/systemd/system, yours in /etc/systemd/system; systemctl edit adds an override, and daemon-reload makes systemd reread files. --user works with your own user manager.