The Frustration of a Slow Boot
There are few things more frustrating than rebooting a Linux server or workstation and waiting several minutes for the login prompt to appear. While Linux is generally known for its stability and speed, a misconfigured service, a failing hard drive, or a network timeout can drastically increase the time it takes for the system to initialize.
When this happens, many administrators resort to guessing. They might start randomly disabling services or combing through thousands of lines in /var/log/syslog hoping to spot a delay.
Modern Linux distributions that use systemd have a built-in, highly visual profiling tool designed specifically for this problem: systemd-analyze. This command can instantly pinpoint exactly which service is acting as the bottleneck during your boot sequence.
Step 1: Getting the High-Level Overview
The first step in troubleshooting is to understand the total time it takes for the system to boot, broken down by the kernel phase and the userspace phase.
Open your terminal and type the command by itself:
systemd-analyze
The output will look something like this:
Startup finished in 3.421s (kernel) + 21.109s (userspace) = 24.531s.
graphical.target reached after 21.050s in userspace.
In this example, the kernel initialized the hardware in just 3.4 seconds, but systemd took 21 seconds to start all the background services (userspace). This tells us the problem isn’t a hardware detection issue; it’s a specific software service causing the delay.
Step 2: Finding the Culprit with “blame”
Now that we know a service is causing the delay, we need to find out which one. The blame subcommand prints a list of all running units, sorted by the time they took to initialize.
Run the following command:
systemd-analyze blame
The output will be a descending list:
12.510s NetworkManager-wait-online.service
4.102s docker.service
2.100s mysql.service
1.050s apache2.service
...Instantly, the culprit is revealed. NetworkManager-wait-online.service took over 12 seconds to start. This specific service forces the boot process to pause until a valid IP address is assigned by the network router. If the network is slow or disconnected, this service will hang the boot process until it hits a built-in timeout.
Note: The times listed in blame are the absolute time that specific service took to start. However, services start in parallel. Just because a service took 5 seconds to start does not necessarily mean it delayed the overall boot time by 5 seconds.
Step 3: Finding the True Bottleneck with “critical-chain”
Because systemd starts services in parallel, we need to see the actual dependency chain. We need to find the critical path—the specific sequence of services that must wait for each other, forming the absolute longest line.
Use the critical-chain subcommand:
systemd-analyze critical-chain
The output will be formatted as a tree:
graphical.target @21.050s
└─multi-user.target @21.050s
└─docker.service @16.948s +4.102s
└─network-online.target @16.940s
└─NetworkManager-wait-online.service @4.430s +12.510s
└─NetworkManager.service @3.100s +1.320sThis output is incredibly powerful. You read it from bottom to top. It shows that NetworkManager started at the 3-second mark. Then, NetworkManager-wait-online started, but it hung for 12.5 seconds (denoted by the +12.510s). Because Docker depends on the network being online, Docker was forced to sit idle until the 16.9-second mark before it could even begin its own 4-second startup routine.
By understanding this chain, you can see that disabling or fixing the networking delay won’t just save 12 seconds; it will also allow Docker to start much earlier, drastically reducing the total boot time.
Step 4: Generating an SVG Graph (Advanced)
If you prefer visual representations, systemd-analyze can generate a highly detailed, colorful vector graphic chart showing the exact start time, end time, and parallel execution of every single service on your system.
Run this command to output the graph to an HTML/SVG file:
systemd-analyze plot > /tmp/boot_graph.svg
You can then open /tmp/boot_graph.svg in any web browser (like Firefox or Chrome). You will see a massive, zoomable timeline that makes identifying overlapping bottlenecks incredibly intuitive.