Ever boot your Linux system and wonder why it's taking so long to get to a login prompt? systemd-analyze blame is your go-to tool for finding out which services are slowing down your boot process.
systemd-analyze is a command-line utility that provides insights into the systemd system and service manager. The blame subcommand specifically shows you how much time each service took to initialize during the last boot, sorted from slowest to fastest.
To see which services are taking the longest to start:
This outputs a list like this:
The times shown represent how long each service took to start, not necessarily when it started in the boot sequence. A service showing 8 seconds doesn't mean it caused an 8-second delay - if it ran in parallel with other services, the actual impact on boot time might be much less.
For a better overview of your entire boot process, use:
This shows summary timing:
This breaks down boot time into distinct phases: firmware initialization, bootloader, kernel loading, and userspace service startup. The userspace time is where most optimization opportunities exist.
To visualize the entire boot process and see which services ran in parallel versus sequentially:
This creates an SVG file showing a timeline of all services during boot. You can open it in any web browser or image viewer. Services appearing as horizontal bars show their start time and duration. Services stacked vertically started in parallel, while services spread horizontally indicate sequential bottlenecks.
To see the dependency chain for a specific service:
Or for a specific target or service:
This shows which services had to wait for others, revealing the critical path through your boot sequence.
Common culprits for slow boot times:
NetworkManager-wait-online.service often appears at the top. This service waits until the network is "online" before considering itself started. If you have network interfaces that take time to connect (or never will, like unplugged ethernet), this creates significant delays. For desktop systems or servers where network connectivity isn't critical for boot, you can disable it:
Similarly, systemd-networkd-wait-online.service does the same thing for systemd-networkd users.
plymouth-quit-wait.service waits for the boot splash screen to finish. On systems without plymouth or where you don't need the splash screen, this is wasted time.
Database services like mariadb.service, postgresql.service, or mongodb.service can take several seconds to initialize, especially on systems with lots of data or slower storage. If these services aren't needed immediately at boot, consider disabling them and starting them manually when needed, or setting them to start after the system is already usable.
When investigating slow boot times, remember that correlation isn't causation. A service showing 8 seconds in the blame output might have started late in the boot process and run in parallel with other services. The critical-chain command is better for understanding actual blocking delays.
For ongoing monitoring, you can compare boot times over time:
Run this periodically and track the numbers. Sudden increases can indicate new problems like failing hardware, misconfigured services, or recent software updates.
If you're optimizing a server, consider which services actually need to start at boot. Many services can be started on-demand using systemd socket activation, or disabled entirely if they're only needed occasionally. Check what's enabled:
For any service you're not sure about, check its purpose:
The real power of systemd-analyze isn't just identifying slow services, but understanding why they're slow and whether they need to run at boot at all. A 10-second service that runs in parallel might have zero impact on boot time, while a 2-second service that blocks everything else can double your boot time.
On systems with particularly complex boot sequences, combining these tools gives you the complete picture. Start with blame to identify candidates, use critical-chain to understand dependencies, and create a plot to visualize everything. From there, you can make informed decisions about what to optimize, disable, or reconfigure.
One final tip: after making changes to service configurations, always reboot and run systemd-analyze again to verify your changes had the expected impact. Sometimes disabling one service reveals another bottleneck that was previously hidden by parallel execution.
systemd-analyze is a command-line utility that provides insights into the systemd system and service manager. The blame subcommand specifically shows you how much time each service took to initialize during the last boot, sorted from slowest to fastest.
To see which services are taking the longest to start:
Code:
systemd-analyze blameThis outputs a list like this:
Code:
8.234s NetworkManager-wait-online.service
5.128s plymouth-quit-wait.service
3.891s systemd-networkd-wait-online.service
2.456s mariadb.service
1.923s docker.service
1.245s firewalld.service
891ms postfix.service
674ms httpd.service
423ms NetworkManager.serviceThe times shown represent how long each service took to start, not necessarily when it started in the boot sequence. A service showing 8 seconds doesn't mean it caused an 8-second delay - if it ran in parallel with other services, the actual impact on boot time might be much less.
For a better overview of your entire boot process, use:
Code:
systemd-analyzeThis shows summary timing:
Code:
Startup finished in 4.392s (firmware) + 2.845s (loader) + 3.124s (kernel) +
12.456s (userspace) = 22.817s
graphical.target reached after 12.234s in userspaceThis breaks down boot time into distinct phases: firmware initialization, bootloader, kernel loading, and userspace service startup. The userspace time is where most optimization opportunities exist.
To visualize the entire boot process and see which services ran in parallel versus sequentially:
Code:
systemd-analyze plot > boot-analysis.svgThis creates an SVG file showing a timeline of all services during boot. You can open it in any web browser or image viewer. Services appearing as horizontal bars show their start time and duration. Services stacked vertically started in parallel, while services spread horizontally indicate sequential bottlenecks.
To see the dependency chain for a specific service:
Code:
systemd-analyze critical-chainOr for a specific target or service:
Code:
systemd-analyze critical-chain graphical.target
systemd-analyze critical-chain sshd.serviceThis shows which services had to wait for others, revealing the critical path through your boot sequence.
Common culprits for slow boot times:
NetworkManager-wait-online.service often appears at the top. This service waits until the network is "online" before considering itself started. If you have network interfaces that take time to connect (or never will, like unplugged ethernet), this creates significant delays. For desktop systems or servers where network connectivity isn't critical for boot, you can disable it:
Code:
sudo systemctl disable NetworkManager-wait-online.serviceSimilarly, systemd-networkd-wait-online.service does the same thing for systemd-networkd users.
plymouth-quit-wait.service waits for the boot splash screen to finish. On systems without plymouth or where you don't need the splash screen, this is wasted time.
Database services like mariadb.service, postgresql.service, or mongodb.service can take several seconds to initialize, especially on systems with lots of data or slower storage. If these services aren't needed immediately at boot, consider disabling them and starting them manually when needed, or setting them to start after the system is already usable.
When investigating slow boot times, remember that correlation isn't causation. A service showing 8 seconds in the blame output might have started late in the boot process and run in parallel with other services. The critical-chain command is better for understanding actual blocking delays.
For ongoing monitoring, you can compare boot times over time:
Code:
systemd-analyze timeRun this periodically and track the numbers. Sudden increases can indicate new problems like failing hardware, misconfigured services, or recent software updates.
If you're optimizing a server, consider which services actually need to start at boot. Many services can be started on-demand using systemd socket activation, or disabled entirely if they're only needed occasionally. Check what's enabled:
Code:
systemctl list-unit-files --state=enabledFor any service you're not sure about, check its purpose:
Code:
systemctl status service-name.serviceThe real power of systemd-analyze isn't just identifying slow services, but understanding why they're slow and whether they need to run at boot at all. A 10-second service that runs in parallel might have zero impact on boot time, while a 2-second service that blocks everything else can double your boot time.
On systems with particularly complex boot sequences, combining these tools gives you the complete picture. Start with blame to identify candidates, use critical-chain to understand dependencies, and create a plot to visualize everything. From there, you can make informed decisions about what to optimize, disable, or reconfigure.
One final tip: after making changes to service configurations, always reboot and run systemd-analyze again to verify your changes had the expected impact. Sometimes disabling one service reveals another bottleneck that was previously hidden by parallel execution.
