Systemd is a system and session manager responsible for managing all of the services that run on the system for the duration of the computer’s operation, from the startup process to shutdown. The processes are always started in parallel (where possible) in order to keep the startup process as short as possible. But how do you know which process took how long when booting your system, well for that we can also use Systemd.
Let’s see Systemd commands to analyze Linux boot time
The steps below can be used for Ubuntu, Linux Mint, CentOS, RHEL, Kali Linux, Debian, MX Linux, Rocky Linux, and other systems booted using Systemd.
Systemd-analyze
systemd-analyze is, as the name suggests, a command line tool from systemd, with which the system, especially the boot process, can be analyzed. The knowledge thus acquired can then be used, for example, to carry out optimizations.
Therefore, to use it, just open your command terminal and immediately check and view the startup processes by running:
systemd-analyze
In the screenshot below, you can see the overview of the system components which need how long to start.
If the operating system is installed on a computer with UEFI, the UEFI boot time (firmware) is also shown. The bootloader start time is then output (loader). The start times for system-related (kernel) components and the user environment are also specified.
Systemd-analyze blame
For a more accurate listing of the data of all services started with system startup, use the blame option. The output data will be sorted according to its start time. With this, the user can find some services which delay the system startup.
Therefore, the most accurate output can be achieved with the command
systemd-analyze blame
This gives you a list of all services along with the start time of the startup.
Linux boot time details in SVG graphics
Those who want to know the boot time details in presentable graphical form can opt for the Ground option. In this case, the output will be exported as SVG graphics. This gives you even more detailed results. the export takes place with
systemd-analyze plot> boot.svg
In the above command, we save the output to boot.svg to file. To open it, use the image viewer. You can simply navigate to the saved image file and double click to open it or use the eog order.
eog boot.svg
However, the exported graph is quite large, therefore, to get a proper view of the process, you have to zoom in and scroll a lot to analyze it. The start time is shown in seconds horizontally. The individual services are listed vertically.
Apart from these commands, you can also use the other Options with systemd-analyze order for more information.
Systemd-analyze commands
| order | Explanation |
time |
Shows how long the system took until the user space was fully loaded and initialized (= until the system can be “used”). The output is divided into firmware, loader(= loading initrd), kernelanduserspace |
blame |
Displays a list of all running devices in systemd, sorted by the time they took to initialize. |
critical-chain |
Displays a “time critical” list of currently running units. Critical time means that the above unit in the list could not be started due to dependencies until the lower unit was fully initialized. |
plot |
Plots the system startup as a diagram in SVG format. Time is plotted on the X axis of the plot and units on the Y axis. The output should be direct to a file redirected to, for example systemd-analyze plot > graph.svg. |
dot |
Generates a unit dependency graph in Graphviz point format. sudo apt install graphviz |
dump |
Displays the status of each loaded unit in detail. Since the list is very long – usually several tens of thousands of lines – the output should either be redirected to a file or filtered directly with grep or something similar. |
verify [UNITDATEI] |
Checks the correctness of all active units. If a unit file is also UNITDATEIspecified, only this unit and the units required to start this unit are checked. Root rights are required for this. |
Conclusion:
The outputs of systemd-analyze are not only interesting, but also allow you to see at a glance why the startup process is taking so long. Services that slow down the startup process can thus be identified directly where lengthy troubleshooting or analysis might otherwise be required.
