Analyzing Linux Boot Performance with systemd‑analyze

System administrators often need to diagnose slow boot times and overall system performance. The systemd‑analyze utility, part of the systemd init system used by most Linux distributions, provides a suite of commands for this purpose.

Measuring total boot time

Running systemd‑analyze time prints a breakdown of the time spent in firmware, loader, kernel, initrd, and userspace. On the author's high‑end workstation the output was:

[root@david ~]$ systemd-analyze time
Startup finished in 53.921s (firmware) + 2.643s (loader) + 2.236s (kernel) + 4.348s (initrd) + 10.082s (userspace) = 1min13.233s
graphical.target reached after 10.071s in userspace

The dominant 54 seconds spent in firmware (BIOS) was unusually long compared with other machines.

Finding the slowest units (blame)

The systemd‑analyze blame command lists all units sorted by the time they took to start:

[root@david ~]$ systemd-analyze blame
5.417s NetworkManager-wait-online.service
3.423s dracut‑initqueue.service
2.715s systemd‑udev‑settle.service
2.519s fstrim.service
1.275s udisks2.service
…

Because many services start in parallel, the sum of the individual times exceeds the total boot time.

Critical chain

The systemd‑analyze critical-chain command shows the sequence of units that form the longest dependency path (the “critical chain”). Each line displays the activation timestamp (preceded by @) and the duration of the unit (after +).

[root@david ~]# systemd-analyze critical-chain
graphical.target @10.071s
└─lxdm.service @10.071s
└─plymouth-quit.service @10.047s+22ms
…

Dumping the full system state

systemd‑analyze dump

outputs a massive amount of information about timestamps, unit states, and configuration details. The author notes that the command produced about 50 000 lines (≈1.66 MiB) on his workstation.

Generating visual plots

The systemd‑analyze plot > /tmp/bootup.svg command creates an SVG file that visualises the boot timeline, with the critical path highlighted in red. The file can be opened with any SVG viewer (e.g., LibreOffice Draw).

[root@david ~]# systemd-analyze plot > /tmp/bootup.svg

Another option is systemd‑analyze dot | dot -Tsvg > /tmp/bootup.svg, which produces a DOT‑based dependency graph that can be rendered to SVG.

Testing unit conditions

The systemd‑analyze condition sub‑command evaluates conditions and assertions defined in a unit file. Example:

[root@david ~]# systemd-analyze condition \
  'ConditionKernelVersion=!<4.0' \
  'ConditionKernelVersion>=5.1' \
  'ConditionACPower=|false' \
  'ConditionArchitecture=|!arm' \
  'AssertPathExists=/etc/os-release'; echo $?
…
0

If all conditions are satisfied the command exits with 0.

Inspecting configuration files

systemd‑analyze cat‑config systemd /system/display‑manager.service

prints the full unit file with a comment showing its path. The output includes sections such as [Unit], [Service], and [Install] with directives like Description, ExecStart, and WantedBy.

Listing matching unit files

systemctl cat backup*

displays the contents of all unit files whose names match the pattern, together with a comment line that shows the absolute file path.

Verifying unit syntax

systemd‑analyze verify /etc/systemd/system/backup.service

checks a unit file for syntax errors. No output means the file passed validation.

Assessing security exposure

The systemd‑analyze security sub‑command evaluates a service unit against a list of security‑related settings (e.g., PrivateNetwork, CapabilityBoundingSet, RestrictAddressFamilies). The tool prints a table of findings and an overall exposure score.

[root@david ~]# systemd-analyze security display-manager
✗ PrivateNetwork=   Service has access to the host's network
✗ User=/DynamicUser= Service runs as root user
…
→ Overall exposure level for backup.service: 9.6 UNSAFE ?

Conclusion

The systemd‑analyze suite offers a rich set of commands for probing boot performance, visualising timelines, checking unit conditions, inspecting configuration, verifying syntax, and evaluating security. While some sub‑commands have limited use cases, together they provide valuable insight for troubleshooting and optimizing systemd‑based Linux systems.