systemd Cheat Sheet
systemd commands and concepts for service lifecycle, unit files, journal logs, timers, and user services.
systemd manages Linux services and other resources as named units with explicit dependencies and activation rules. systemctl controls the manager, while journalctl reads the structured journal produced by units and the wider system.
Unit types and search paths
The suffix identifies what a unit represents. A unit may activate another unit, so a socket or timer commonly points to a service with the same base name.
| Suffix | Resource |
|---|---|
.service | A process or group of processes. |
.socket | A listening IPC or network socket. |
.timer | Calendar-based or monotonic activation. |
.target | A synchronization group of units. |
.mount | A filesystem mount point. |
.path | Activation triggered by filesystem changes. |
| Path | Typical purpose |
|---|---|
/etc/systemd/system/ | Administrator-managed system units and overrides. |
/run/systemd/system/ | Runtime-generated units that disappear at reboot. |
/usr/lib/systemd/system/ | Vendor or package-managed system units. |
/lib/systemd/system/ | Vendor unit location used by some distributions. |
~/.config/systemd/user/ | Units for one user's service manager. |
Prefer an override under /etc/systemd/system/UNIT.d/ to editing a package-owned file. systemctl cat shows the fragments and drop-ins that form the effective unit.
systemctl cat sshd.service
systemctl show -p FragmentPath sshd.service
Service lifecycle and enablement
Starting and stopping affect the current runtime. Enabling and disabling add or remove boot-time dependency links; they do not imply an immediate start or stop unless --now is included.
sudo systemctl start example.service
sudo systemctl stop example.service
sudo systemctl restart example.service
sudo systemctl reload example.service
sudo systemctl enable example.service
sudo systemctl disable example.service
sudo systemctl enable --now example.service
sudo systemctl disable --now example.service
| Command | Meaning |
|---|---|
reload UNIT | Ask a running unit to reload its own configuration, if supported. |
restart UNIT | Stop and start the unit. |
try-restart UNIT | Restart only when it is already active. |
is-active UNIT | Report whether the unit is active. |
is-enabled UNIT | Report its enablement state. |
mask UNIT | Prevent manual and dependency-based starts. |
unmask UNIT | Remove that hard block. |
Inspect and discover units
list-units reports units loaded into the current manager; list-unit-files reports installed unit files and their enablement state, including units that are not loaded.
systemctl status example.service
systemctl list-units --type=service --state=running
systemctl list-units --failed
systemctl list-unit-files --type=service
systemctl list-dependencies example.service
systemctl list-timers --all
| State | Interpretation |
|---|---|
active (running) | A long-running service has a live main process. |
active (exited) | A successful one-shot unit remains logically active. |
inactive | The unit is not currently active. |
failed | The last activation or runtime ended unsuccessfully. |
Use systemctl reset-failed UNIT after addressing a failure when the recorded failed state or start-rate limit needs clearing.
Journal queries
Journal filters can be combined. Put -u and -f together to follow one unit instead of streaming every new system message.
journalctl -u example.service
journalctl -u example.service -f
journalctl -u example.service --since "today"
journalctl -u example.service --since "2026-07-29 09:00" --until "2026-07-29 10:00"
journalctl -p warning
journalctl -b
journalctl -b -1
| Option | Result |
|---|---|
-f | Follow newly appended entries. |
-u UNIT | Restrict output to a unit. |
--since TIME | Start at a timestamp or relative expression. |
-p LEVEL | Filter by syslog priority, such as warning or err. |
-b [ID] | Select the current or another boot. |
-n COUNT | Show a limited number of recent entries. |
Service unit anatomy and edits
A local service can be placed at /etc/systemd/system/report-worker.service. ExecStart runs directly rather than through a shell, so shell operators require an explicit shell command when they are genuinely needed.
[Unit]
Description=Report worker
Wants=network-online.target
After=network-online.target
[Service]
Type=simple
ExecStart=/usr/local/bin/report-worker --foreground
Restart=on-failure
RestartSec=5s
[Install]
WantedBy=multi-user.target
| Directive | Purpose |
|---|---|
Type=simple | Treat the ExecStart process as the main service process. |
Type=forking | Expect the startup process to fork and its parent to exit; older daemons may also need PIDFile=. |
ExecStart= | Define the executable and arguments used to start the service. |
Restart=on-failure | Restart after unsuccessful exits or abnormal termination. |
Restart=always | Restart after clean and unsuccessful exits, except an explicit manager stop. |
WantedBy=multi-user.target | Create an enablement relationship to that target. |
After creating or editing unit files, reload the manager's definitions and then restart the affected service if the running process must pick up the change:
sudo systemctl daemon-reload
sudo systemctl restart report-worker.service
daemon-reload reparses unit files; it does not reload application configuration or restart services by itself.
Timers and user services
A timer activates a corresponding service. Calendar timers resemble cron schedules, while monotonic timers express elapsed time from events such as boot or the previous activation.
/etc/systemd/system/backup.service:
[Unit]
Description=Create application backup
[Service]
Type=oneshot
ExecStart=/usr/local/bin/create-backup
/etc/systemd/system/backup.timer:
[Unit]
Description=Run the application backup nightly
[Timer]
OnCalendar=*-*-* 02:00:00
Persistent=true
RandomizedDelaySec=10m
[Install]
WantedBy=timers.target
| Timer directive | Use |
|---|---|
OnCalendar= | Run at wall-clock calendar times. |
OnBootSec= | Run after a duration measured from boot. |
OnUnitActiveSec= | Run after a duration measured from the last activation. |
Persistent=true | Catch up a missed calendar activation after downtime. |
Compared with cron, timers integrate dependency ordering, service isolation, journal output, and missed-run handling. Enable the .timer, not the service, for scheduled activation.
sudo systemctl daemon-reload
sudo systemctl enable --now backup.timer
systemctl list-timers --all
User units use the per-user manager and normally live in ~/.config/systemd/user/:
systemctl --user daemon-reload
systemctl --user enable --now report.service
systemctl --user status report.service
journalctl --user -u report.service -f
A user manager commonly stops after the user's final logout. An administrator can enable lingering with loginctl enable-linger USER when approved user services must continue without an interactive session.