systemd-analyze, security review, and boot diagnostics · Linux

systemd ships a self-diagnostic tool: systemd-analyze. Three modes cover the most common production investigations.

systemd-analyze security scores a unit on the sandboxing and resource directives it sets. This lesson uses it as a diagnostic — read the score, understand what it is measuring — and does not require you to know those directives yet. Part XXXVII covers them in full, and is where you go to act on a bad score.

Time spent at boot

Read-only / Safesystemd-analyze— Boot time: kernel (initramfs to PID 1) + userspace (systemd start to default.target) = total. The 'graphical.target reached after N' line tells you where time went in userspace.

$ systemd-analyze

Startup finished in 1.234s (kernel) + 4.567s (userspace) = 5.801s
graphical.target reached after 4.501s in userspace

Illustrative output

Read-only / Safesystemd-analyze blame— blame lists every unit that contributed to boot time, slowest first. A single slow unit is a candidate for optimization. The top entry is where to start.

$ systemd-analyze blame | head

5.123s myapp.service
1.234s sshd.service
0.890s NetworkManager-wait-online.service
0.456s chrony.service
...

Illustrative output

Read-only / Safecritical-chain— critical-chain shows the dependency chain that led to the named unit becoming active. The @time +duration format shows when the chain element started and how long it took. sshd.service waited 1.234s after network-online.target because of its own startup; NetworkManager-wait-online.service added another 0.067s.

$ systemd-analyze critical-chain sshd.service

The time when unit became active with startup times in parentheses.
multi-user.target @4.501s
└─sshd.service @3.267s +1.234s
└─network-online.target @3.200s +0.067s
└─NetworkManager-wait-online.service @3.133s +0.067s
└─NetworkManager.service @2.500s +0.633s

Illustrative output

boot-time discipline

A common production discipline is a boot-time budget. A service that boots in 5 seconds is fine; a service that adds 5 seconds to every host’s boot time is a fleet-wide problem.

Check the budget with systemd-analyze critical-chain, not with blame. blame ranks units by their own start duration regardless of whether anything was waiting on them — a unit that takes 5 seconds while thirty others start alongside it costs the boot nothing, and it will still sit at the top of the list. Optimising the top of blame is how people spend an afternoon shaving a unit that was never on the critical path.

critical-chain shows what actually serialised the boot. Use it to find the chain, then use blame to size the candidates it surfaces:

systemd-analyze critical-chain          # what is serialising the boot
systemd-analyze blame | head -20        # how big are those units

For a fleet that boots hundreds or thousands of hosts in parallel (e.g., autoscaling groups), even a 1-second boot-time saving compounds. Reduce expensive After= dependencies, parallelise where possible, and defer non-essential services to a Wants= dependency rather than a Requires=.

Security review

Read-only / Safesecurity review— systemd-analyze security produces a list of security weaknesses ranked by exposure score. The ✗ indicates a finding; check ✓ items have appropriate hardening. The exposure score is a rough heuristic; even 0.1 is worth investigating.

$ systemd-analyze security myapp.service

  NAME                                 DESCRIPTION                              EXPOSURE
✗ RootDirectory/EmergencyUID           Service runs as root                      0.5
✗ User=/DynamicUser=                   Service runs as root                      0.4
✗ SupplementaryGroups=                 Has supplementary groups                  0.1
✗ PrivateDevices=                      Service has access to /dev               0.2
✗ ProtectSystem=                       Filesystem is shared                      0.6
✗ ProtectHome=                         Service has access to /home              0.1
✗ MountAPI=                            Service may mount filesystems             0.3
✗ RestrictAddressFamilies=             Service may use AF_INET, AF_UNIX         0.1
✗ RestrictNamespaces=                  Service may create namespaces             0.4
✗ SystemCallArchitectures=             Service may use non-native arch           0.2
...

Illustrative output

The security analysis checks dozens of hardening directives:

RootDirectory / User — runs as root.
SupplementaryGroups — has supplementary groups.
PrivateDevices / PrivateNetwork / PrivateTmp — namespace isolation.
ProtectSystem / ProtectHome — filesystem visibility.
SystemCallFilter / SystemCallArchitectures — syscall restrictions.
CapabilityBoundingSet — capability restrictions.
NoNewPrivileges — cannot escalate.

Read-only / Safeoffline security audit— --offline=true analyses unit FILES rather than the running system, so it works in CI on a checkout with no systemd running. It requires the unit paths as arguments - with none it exits with 'Option --offline= requires one or more units to perform a security review'.

$ systemd-analyze security --offline=true ./myapp.service

✓ PrivateMounts=       Service cannot install system mounts
✗ UMask=               Files created by service are world-readable by default   0.1

→ Overall exposure level for myapp.service: 8.9 EXPOSED 🙁

Illustrative output

--offline=true needs the units named. Without them it does not fall back to scanning anything:

$ systemd-analyze security --offline=true --user
Option --offline= requires one or more units to perform a security review.

For CI, add --threshold= so the exposure score becomes a pass or fail rather than something a human has to read. It exits non-zero when any unit scores above the threshold:

# Fails the build if any unit is worse than 50
systemd-analyze security --offline=true --threshold=50 \
    ./units/*.service

Pick the threshold from where your units are today and ratchet it down, rather than starting at a number nothing passes.

Plot SVG

Read-only / Safeboot plot— Plot produces an SVG visualising boot timing — every service as a horizontal bar. Useful in post-mortems and design docs.

$ systemd-analyze plot > boot.svg

Illustrative output

Common findings

Finding	Fix
Service runs as root	Add `User=myapp`, `Group=myapp`; add `DynamicUser=yes` if no persistent state
`ProtectSystem=full` or unset	Set `ProtectSystem=strict`, then re-open only what the service writes with `StateDirectory=`, `LogsDirectory=`, `RuntimeDirectory=` or `ReadWritePaths=`. Applied alone, `strict` breaks any service with persistent state at its first write
`PrivateDevices=no`	Set `PrivateDevices=true`
`SystemCallFilter=` unset	Add an explicit `@system-service` filter
Boot time > 30s	Run `systemd-analyze blame` to find the slow unit; consider deferring with `WantedBy=`

Time spent at boot

Security review

Plot SVG

Common findings

Knowledge check