systemctl and journalctl · systemd Essentials

Once a unit exists, systemctl is how you inspect and control it, and journalctl is how you read what it printed.

Everyday systemctl

bash

systemctl daemon-reload                # after editing any unit file
systemctl start   example-api.service
systemctl status  example-api.service
systemctl enable  example-api.service  # start at boot
systemctl restart example-api.service
systemctl list-units --type=service --state=running

Tip

Forgetting `systemctl daemon-reload` after editing a unit is the single most common systemd mistake. systemd keeps a parsed copy in memory and will happily keep using the old one.

Reading logs

systemd captures stdout and stderr of every service into the journal, so a service does not need to manage its own log files.

bash

journalctl -u example-api.service        # everything this unit logged
journalctl -u example-api.service -f     # follow, like tail -f
journalctl -u example-api.service -b     # only since the last boot
journalctl -u example-api.service -p err # errors and worse
journalctl --since '10 min ago'

Overrides without touching the original

`systemctl edit` opens an empty drop-in file. Only the directives you write there are changed; everything else is inherited from the packaged unit.

bash

systemctl edit example-api.service
# writes /etc/systemd/system/example-api.service.d/override.conf

Recap

daemon-reload after every unit file change, or systemd keeps the stale copy.
enable sets boot behaviour; start affects only the running system.
journalctl -u <unit> -f is the equivalent of tail -f on a service log.
systemctl edit creates a drop-in override and leaves the packaged unit intact.