On a slow-booting systemd host, systemd-analyze blame reports that a unit took 25 seconds, but disabling it does not shorten the boot at all. Why can blame mislead, and which systemd-analyze subcommand answers "what is actually delaying the boot"?

## Start by splitting the boot Before blaming any unit, find out which phase the time is in: ```bash $ systemd-analyze Startup finished in 4.1s (firmware) + 2.3s (loader) + 3.8s (kernel) + 1.9s (initrd) + 12.4s (userspace) = 24.6s ``` If the userspace number is small, no amount of unit tuning will help — the time is in firmware (server BIOS memory training and option ROMs routinely cost tens of seconds), the boot loader menu timeout, or the kernel and initrd. Candidates who jump straight to `blame` skip this and end up optimising the wrong phase. ## What blame measures — and does not ```bash $ systemd-analyze blame 25.104s cloud-final.service 8.221s dnf-makecache.service 3.019s NetworkManager-wait-online.service ... ``` This is a per-unit initialisation duration, sorted descending. Two structural blind spots: 1. **No graph.** Units start in parallel. If nothing in the chain to `default.target` is ordered after `cloud-final.service`, its 25 seconds overlap with everything else and contribute nothing to the total. Disabling it changes the list and not the boot. 2. **Blocking is counted as work.** A unit that spends its time waiting for a dependency still shows the wall-clock duration. So the slowest entry is sometimes a *victim* of the real culprit rather than the culprit itself. blame is still useful — it is the right tool for "which unit is doing something expensive" — but it does not answer "what made the boot long". ## critical-chain: the graph-aware view ```bash $ systemd-analyze critical-chain multi-user.target @14.882s └─sshd.service @14.101s +780ms └─network-online.target @14.098s └─NetworkManager-wait-online.service @11.077s +3.019s └─NetworkManager.service @10.462s +603ms └─dbus.service @10.455s └─basic.target @10.301s ``` Read the two markers carefully, because they mean different things: - `@` is the point in time at which the unit became active — an absolute offset from boot. - `+` is how long that unit itself took to start. A chain where the `@` values jump but the `+` values are small means the delay is *between* units — usually something waiting on a target. A single large `+` is a unit that is genuinely slow. In the example above, three of the fifteen seconds are `NetworkManager-wait-online.service` doing its job; the rest accumulated earlier in the chain. You can also aim it at a specific unit — `systemd-analyze critical-chain sshd.service` — to see the chain that gated *that* service rather than the default target. Its own caveat, which the man page states: the output can still mislead, because socket activation and parallel execution mean the displayed chain is not necessarily the whole story of what a unit was waiting for. ## plot, when the chain is not enough ```bash systemd-analyze plot > boot.svg ``` This renders every unit as a bar on a shared timeline, so overlap is visible directly. It is the tool for "three things all finish at 11s — what were they waiting for?", and it makes serialisation obvious in a way a text tree does not. ## Then ask why, not just what Once you have a real culprit, the analysis tools stop and ordinary triage begins: read the unit's logs for that boot with `journalctl -u <unit> -b`, check what it is ordered after with `systemctl list-dependencies --after <unit>`, and confirm the unit file is what you think it is with `systemctl cat`. The usual findings are dull and repeatable — a wait-online service blocking on an interface that will never come up, a mount ordered against an unreachable NFS server, a `Type=oneshot` unit doing network I/O inside `ExecStart`, or a metadata refresh running at boot that belongs on a timer. ## The fixes that actually shorten a boot Most of the time you are removing an ordering edge rather than making a unit faster: move work off the critical chain by not gating other units on it, convert a boot-time job into a timer unit that runs a minute after boot, or narrow a wait-online configuration to the interface that matters. Making the slow unit itself faster is usually the last option, not the first — and it is worth nothing at all if the unit was never on the chain.