Troubleshoot Slow Linux Boot: systemd-analyze blame

A slow Linux boot sequence is often caused by misconfigured services, network timeouts, or hardware initialization bottlenecks managed by systemd. The systemd-analyze blame command serves as a primary diagnostic tool within modern Linux distributions, profiling the boot process by ranking every active service according to the initialization time it consumed. This article covers how systemd-analyze blame works, how to interpret its output, how to cross-reference it with the critical chain, and the practical steps to resolve services that hinder system startup.

Understanding systemd-analyze blame

In systemd-based Linux systems, the init system initializes services in parallel whenever possible to reduce total boot time. The systemd-analyze blame command inspects the system log for the most recent boot and prints an ordered list of all running units, sorted from the longest initialization time to the shortest.

To run the command, open a terminal and execute:

systemd-analyze blame

The output displays elapsed time alongside the corresponding unit name:

12.345s NetworkManager-wait-online.service
 4.120s plymouth-quit-wait.service
 2.890s docker.service
 1.450s systemd-udev-settle.service
  820ms dev-sda1.device

Each duration indicates how long that specific unit took to start during the boot phase.

Interpreting the Output Correctly

While systemd-analyze blame clearly exposes slow services, high values do not always mean a service directly delayed the total boot time. Because systemd executes tasks concurrently, a service that takes ten seconds might run entirely in the background while other critical tasks finish.

Common units that appear at the top of the blame list include:

• NetworkManager-wait-online.service: Holds the boot sequence until an active network connection is confirmed. On systems with static interfaces, slow DHCP responses, or missing Wi-Fi credentials, this service frequently stalls the boot process.
• systemd-udev-settle.service: Waits for all udev events to complete. It is often triggered by slow or unresponsive hardware devices, legacy storage, or outdated kernel modules.
• Heavy Daemons (docker.service, snapd.service, mysqld.service): Large application services that perform internal database scans, image verifications, or socket checks upon initialization.

Cross-Referencing with the Critical Chain

To determine whether a slow unit listed in blame actually delayed your login prompt or graphical interface, use the critical chain command:

systemd-analyze critical-chain

The critical chain output highlights the serialized path of dependencies that blocked other components from loading. When a service appears with high duration in both blame and critical-chain, it directly slowed down the overall boot.

Resolving Boot Bottlenecks

Once you identify the problematic unit using systemd-analyze blame, take the appropriate corrective action:

1. Inspect Service Logs

Check the detailed logs of the slow service to see what caused the delay:

journalctl -u <service-name>.service -b

Review the timestamps to locate specific timeouts or stalled operations.

2. Disable Unnecessary Services

If a slow service is not essential for system operation or remote access, disable it so it does not load automatically at boot:

sudo systemctl disable <service-name>.service

3. Handle Network Delays

If NetworkManager-wait-online.service causes delays on a desktop machine where a network is not strictly required before login, disable it:

sudo systemctl disable NetworkManager-wait-online.service

Alternatively, restrict it to wait only on specific active network interfaces rather than all possible adapters.

4. Mask Unwanted Deprecated Units

For services like systemd-udev-settle.service that may no longer be required by modern storage setups, you can mask the unit to completely prevent other services from triggering it:

sudo systemctl mask systemd-udev-settle.service

Regularly auditing your startup chain with systemd-analyze blame after kernel updates, software installations, or configuration changes ensures your Linux system consistently achieves optimal boot times.