Tools

Tools: Stop Guessing Why Linux Boots Slowly: Practical `systemd-analyze` for Real Bottlenecks (2026)

2026-05-14 0 views admin
Tools: Stop Guessing Why Linux Boots Slowly: Practical `systemd-analyze` for Real Bottlenecks (2026)

Stop Guessing Why Linux Boots Slowly: Practical systemd-analyze for Real Bottlenecks

What systemd-analyze time really measures

Step 1: Use blame, but don't trust it blindly

Step 2: Find the real blocker with critical-chain

Step 3: Generate a boot chart you can inspect visually

Step 4: Identify who actually requested the slow thing

Step 5: Fix the dependency, not the symptom

Safer fix pattern A: wait only for the interface that matters

Safer fix pattern B: override the wait behavior

Important warning

Step 6: Re-measure after every change

A practical workflow that holds up

Final thought

References If a Linux system feels slow to boot, the tempting move is to scan systemd-analyze blame, spot the biggest number, and disable whatever looks guilty. That works just often enough to be dangerous. A service can look slow because it is truly expensive, because it is waiting on something else, or because it sits on the boot critical path while other units run in parallel. The useful question is not "what has the biggest number?" It is "what is actually delaying the target I care about?" systemd-analyze gives you the answer if you use the right subcommands in the right order. In this guide, I'll show a practical workflow to: Start with the baseline: This is useful, but it is narrower than many people assume. According to the systemd-analyze(1) manual, this measures: It does not guarantee the system is fully idle or that every service finished all of its work. Treat it as a boot baseline, not a complete performance profile. Now list the slowest-starting units: This is a good shortlist, but it is not a causal graph. The man page explicitly warns that blame can be misleading: So blame tells you what took time, not necessarily what delayed boot. This is the command that usually matters most: This shows the path that actually delayed the target. In the example above, systemd-networkd-wait-online.service is on the critical path. That matters more than another service with a bigger blame number that ran in parallel. If you only use one command after time, make it critical-chain. For messy boots, a picture helps: This generates an SVG timeline showing when each unit started and how long initialization took. If you're working over SSH, copy the file locally and open it in a browser. A common boot delay is network-online.target or a wait-online service. The right fix is often not disabling it globally. The right fix is finding what needs it. First inspect the reverse dependencies: Then inspect the target itself: This is where the diagnosis gets real: The systemd.special(7) manual makes an important distinction here: That distinction is easy to miss, and it explains a lot of "mystery slow boots." Let's use a very common example: systemd-networkd-wait-online.service. The systemd-networkd-wait-online.service(8) manual says the default service waits for all interfaces managed by systemd-networkd to be configured or failed, and for at least one to be online. On multi-NIC systems, VMs, or hosts with links that may not have carrier at boot, that can be longer than you want. If only one interface matters for boot-critical consumers, use the instance unit: That switches from "wait for everything" to "wait for eth0." Use something like this: Then reload and test on the next boot: That tells the service to stop waiting for every managed link and to fail faster if the expected condition is not met. Do not blindly remove wait-online behavior on systems that need: The goal is targeted boot optimization, not shaving seconds by breaking startup ordering. After each boot change, run the same small checklist: If you want a before/after record: That makes it much easier to verify whether a change actually improved the path to multi-user.target or graphical.target. When a Linux boot feels slow, this is the sequence I trust: That flow answers five different questions: That is a much better place to start than disabling services because their names look suspicious. Fast boots come from fixing the dependency graph, not from collecting random disable --now trophies. systemd-analyze blame is a hint. critical-chain is the diagnosis. The SVG plot is the sanity check. Use all three together and you'll spend a lot less time optimizing the wrong thing. Templates let you quickly answer FAQs or store snippets for re-use. Are you sure you want to ? It will become hidden in your post, but will still be visible via the comment's permalink. Hide child comments as well For further actions, you may consider blocking this person and/or reporting abuse

Code Block

Copy

systemd-analyze systemd-analyze blame systemd-analyze systemd-analyze time systemd-analyze time systemd-analyze time systemd-analyze time Startup finished in 3.415s (kernel) + 6.712s (userspace) = 10.128s graphical.target reached after 6.492s in userspace. Startup finished in 3.415s (kernel) + 6.712s (userspace) = 10.128s graphical.target reached after 6.492s in userspace. Startup finished in 3.415s (kernel) + 6.712s (userspace) = 10.128s graphical.target reached after 6.492s in userspace. systemd-analyze(1) systemd-analyze blame | head -n 15 systemd-analyze blame | head -n 15 systemd-analyze blame | head -n 15 4.277s apt-daily.service 1.672s systemd-networkd-wait-online.service 1.653s apt-daily-upgrade.service 1.636s fstrim.service 1.567s cloud-init-main.service 4.277s apt-daily.service 1.672s systemd-networkd-wait-online.service 1.653s apt-daily-upgrade.service 1.636s fstrim.service 1.567s cloud-init-main.service 4.277s apt-daily.service 1.672s systemd-networkd-wait-online.service 1.653s apt-daily-upgrade.service 1.636s fstrim.service 1.567s cloud-init-main.service Type=simple critical-chain systemd-analyze critical-chain systemd-analyze critical-chain systemd-analyze critical-chain graphical.target @6.492s └─multi-user.target @6.490s └─tailscaled.service @5.680s +806ms └─basic.target @5.558s └─sockets.target @5.556s └─uuidd.socket @5.554s └─sysinit.target @5.513s └─cloud-init-network.service @5.104s +395ms └─systemd-networkd-wait-online.service @3.427s +1.672s graphical.target @6.492s └─multi-user.target @6.490s └─tailscaled.service @5.680s +806ms └─basic.target @5.558s └─sockets.target @5.556s └─uuidd.socket @5.554s └─sysinit.target @5.513s └─cloud-init-network.service @5.104s +395ms └─systemd-networkd-wait-online.service @3.427s +1.672s graphical.target @6.492s └─multi-user.target @6.490s └─tailscaled.service @5.680s +806ms └─basic.target @5.558s └─sockets.target @5.556s └─uuidd.socket @5.554s └─sysinit.target @5.513s └─cloud-init-network.service @5.104s +395ms └─systemd-networkd-wait-online.service @3.427s +1.672s systemd-networkd-wait-online.service critical-chain systemd-analyze plot > bootup.svg xdg-open bootup.svg systemd-analyze plot > bootup.svg xdg-open bootup.svg systemd-analyze plot > bootup.svg xdg-open bootup.svg network-online.target systemctl list-dependencies --reverse --no-pager network-online.target systemctl list-dependencies --reverse --no-pager network-online.target systemctl list-dependencies --reverse --no-pager network-online.target network-online.target ● ├─cloud-config.service ● ├─cloud-final.service ● └─exim4.service network-online.target ● ├─cloud-config.service ● ├─cloud-final.service ● └─exim4.service network-online.target ● ├─cloud-config.service ● ├─cloud-final.service ● └─exim4.service systemctl show -p Wants -p Requires -p Before -p After network-online.target systemctl show -p Wants -p Requires -p Before -p After network-online.target systemctl show -p Wants -p Requires -p Before -p After network-online.target Requires= Wants=systemd-networkd-wait-online.service Before=apt-daily.service cloud-final.service exim4.service After=systemd-networkd-wait-online.service cloud-init-network.service network.target Requires= Wants=systemd-networkd-wait-online.service Before=apt-daily.service cloud-final.service exim4.service After=systemd-networkd-wait-online.service cloud-init-network.service network.target Requires= Wants=systemd-networkd-wait-online.service Before=apt-daily.service cloud-final.service exim4.service After=systemd-networkd-wait-online.service cloud-init-network.service network.target network-online.target systemd.special(7) network.target network-online.target systemd-networkd-wait-online.service systemd-networkd-wait-online.service(8) systemd-networkd sudo systemctl disable systemd-networkd-wait-online.service sudo systemctl enable [email protected] sudo systemctl reboot sudo systemctl disable systemd-networkd-wait-online.service sudo systemctl enable [email protected] sudo systemctl reboot sudo systemctl disable systemd-networkd-wait-online.service sudo systemctl enable [email protected] sudo systemctl reboot sudo systemctl edit systemd-networkd-wait-online.service sudo systemctl edit systemd-networkd-wait-online.service sudo systemctl edit systemd-networkd-wait-online.service [Service] ExecStart= ExecStart=/usr/lib/systemd/systemd-networkd-wait-online --any --interface=eth0 --timeout=15 [Service] ExecStart= ExecStart=/usr/lib/systemd/systemd-networkd-wait-online --any --interface=eth0 --timeout=15 [Service] ExecStart= ExecStart=/usr/lib/systemd/systemd-networkd-wait-online --any --interface=eth0 --timeout=15 sudo systemctl daemon-reload sudo systemctl reboot sudo systemctl daemon-reload sudo systemctl reboot sudo systemctl daemon-reload sudo systemctl reboot systemd-analyze time systemd-analyze blame | head -n 15 systemd-analyze critical-chain systemd-analyze time systemd-analyze blame | head -n 15 systemd-analyze critical-chain systemd-analyze time systemd-analyze blame | head -n 15 systemd-analyze critical-chain mkdir -p ~/boot-profiles stamp=$(date +%F-%H%M%S) { echo "## $stamp" systemd-analyze time echo systemd-analyze blame | head -n 20 echo systemd-analyze critical-chain } > ~/boot-profiles/$stamp.txt mkdir -p ~/boot-profiles stamp=$(date +%F-%H%M%S) { echo "## $stamp" systemd-analyze time echo systemd-analyze blame | head -n 20 echo systemd-analyze critical-chain } > ~/boot-profiles/$stamp.txt mkdir -p ~/boot-profiles stamp=$(date +%F-%H%M%S) { echo "## $stamp" systemd-analyze time echo systemd-analyze blame | head -n 20 echo systemd-analyze critical-chain } > ~/boot-profiles/$stamp.txt multi-user.target graphical.target systemd-analyze time systemd-analyze blame | head -n 15 systemd-analyze critical-chain systemd-analyze plot > bootup.svg systemctl list-dependencies --reverse --no-pager network-online.target systemd-analyze time systemd-analyze blame | head -n 15 systemd-analyze critical-chain systemd-analyze plot > bootup.svg systemctl list-dependencies --reverse --no-pager network-online.target systemd-analyze time systemd-analyze blame | head -n 15 systemd-analyze critical-chain systemd-analyze plot > bootup.svg systemctl list-dependencies --reverse --no-pager network-online.target disable --now systemd-analyze blame critical-chain systemd-analyze(1) systemd.special(7) systemd-networkd-wait-online.service(8) - measure boot time correctly - identify the real boot bottleneck - visualize the boot path - inspect who is pulling in a slow dependency - make targeted fixes instead of random boot-time surgery - time in the kernel before userspace - time in the initrd, if one exists - time until normal userspace has spawned system services - a unit may look slow because it is waiting for another unit - units of Type=simple do not show meaningful startup timing here - it only reports time spent in the activating state - @ = when the unit became active - + = how long that unit itself took to start - you can see parallelism vs serialization - you can spot long waits before a unit even starts - you can distinguish "slow unit" from "slow dependency chain" - if nothing important depends on network-online.target, boot delay may be accidental - if remote mounts depend on it, the wait may be justified - if only one consumer needs it, fix that consumer or narrow the wait condition - network.target is a passive synchronization point and usually does not add much delay - network-online.target is an active target used by consumers that strictly require configured networking, and it can add substantial boot delay - remote filesystems - network-backed identity or config on boot - cloud-init stages that expect usable networking - services that genuinely must start only after routable connectivity exists - How long did boot take? - Which units consumed time? - Which chain delayed the final target? - What did parallel startup actually look like? - Which unit asked for the expensive dependency? - systemd-analyze(1): https://manpages.debian.org/bookworm/systemd/systemd-analyze.1.en.html - systemd.special(7): https://manpages.debian.org/bookworm/systemd/systemd.special.7.en.html - systemd-networkd-wait-online.service(8): https://manpages.debian.org/bookworm/systemd/systemd-networkd-wait-online.service.8.en.html

🏷️ Tags

toolsutilitiessecurity toolsguessinglinuxbootsslowlypracticalsystemdanalyze

More from Tools

Tools: Eu quero vibe-codar 😎🤖 - Guide

Tools: Eu quero vibe-codar 😎🤖 - Guide

2026-05-14 0
Tools: Laravel CI/CD with GitHub Actions: Tests, Code Quality, and Deployment (2026)

Tools: Laravel CI/CD with GitHub Actions: Tests, Code Quality, and Deployment (2026)

2026-05-14 0
Tools: CI/CD Broke Under Agents: The Continuous Compute Stack - Expert Insights

Tools: CI/CD Broke Under Agents: The Continuous Compute Stack - Expert Insights

2026-05-14 0
Tools: The Mystery of the Redis Read-Only Error in a Single-Node Setup

Tools: The Mystery of the Redis Read-Only Error in a Single-Node Setup

2026-05-14 0

Trending

1

CVE-2025-61481: Critical Remote Code Execution Vulnerability in MikroTik RouterOS & SwitchOS

2025-10-27 • 189 views
2

CVE-2025-43939: Dell Unity OS Command Injection (High)

2025-10-30 • 148 views
3

Google disputes false claims of massive Gmail data breach

2025-10-30 • 130 views
4

Microsoft: DNS outage impacts Azure and Microsoft 365 services

2025-10-30 • 88 views
5

3.5B Accounts, 1 Critical Flaw: Meta Closes WhatsApp Data-Harvesting

2025-11-25 • 81 views