Linux Command #65 — systemd-analyze (Linux OS). When a Linux workstation or server takes longer than expected to boot, guessing which service is responsible can waste time and create risk. The systemd-analyze utility reports startup timing and helps explain which units affected the boot sequence. This focused command lesson follows Linux Command #64 — localectl and concentrates on read-only boot-time diagnosis. It does not instruct learners to disable system services.

Learning objectives

• Read total startup timing with systemd-analyze time.
• Rank unit initialization durations using systemd-analyze blame without mistaking the list for a list of causes.
• Read the dependency timing presented by systemd-analyze critical-chain.
• Recognize the limitations of phase timing, socket activation, hardware waits and parallel startup.
• Create a safe diagnostic note before considering configuration changes.

What is systemd-analyze?

On many modern distributions, systemd is the service manager that starts units such as daemons, sockets, mounts and targets. The command systemd-analyze queries systemd for diagnostic and timing information; systemctl, by contrast, is commonly used to inspect or change unit states. Many systemd-analyze subcommands are informative and read-only. The tool also supports configuration verification and security analysis, but this chapter teaches only timing inspection.

Before assuming a Linux machine follows this pattern, confirm that it actually runs a compatible systemd service manager. Some minimal containers, specialized appliances and alternative Linux distributions use other init systems or do not expose complete boot timing information. For the broader boot sequence—firmware, bootloader, kernel, initramfs and service manager—see How Linux Boots.

1. Inspect the boot-duration summary

The first command is systemd-analyze time. The time subcommand is optional; running systemd-analyze alone commonly displays the same report. The output may list firmware, loader, kernel, initrd and userspace phases, depending on the platform and available measurement support. The displayed total refers to recorded startup phases; it does not guarantee that the graphical desktop is responsive or that every application has fully initialized.

$ systemd-analyze time
Startup finished in 2.400s (kernel) + 3.100s (initrd) + 5.700s (userspace) = 11.200s
multi-user.target reached after 5.600s in userspace

Illustrative output, not a measurement from a particular computer. Add the reported phases to confirm the arithmetic: 2.4 + 3.1 + 5.7 = 11.2 seconds. The multi-user.target time is a milestone within the userspace phase; it should not be added a second time. EFI firmware and loader timing can be omitted where no supported measurements are available.

2. Find slow-starting units with blame

Run systemd-analyze blame to rank currently known units according to how long they spent initializing. The official manual cautions that this ranking can be misleading: services commonly start in parallel, some waits are not represented as unit activation time, and services of certain types—such as Type=simple—may not show meaningful activation delays. The top entry is a candidate for investigation, not necessarily the cause of total boot latency.

$ systemd-analyze blame
8.500s systemd-networkd-wait-online.service
3.100s example-database.service
1.400s example-monitor.service
 680ms systemd-journald.service

Illustrative ranking only. The 8.5-second entry does not imply that the overall boot would become 8.5 seconds faster if that service were disabled. The wait could overlap other startup tasks, and the unit might satisfy an important dependency. On a remote production server, disconnecting a required network service is especially costly.

Video study — a focused systemd-analyze walkthrough

The LinuxHowTo tutorial demonstrates the basic time, blame and graphical timing commands. Treat the video’s optimization suggestions as examples to evaluate, not automatic instructions to disable or mask units. The commands in this chapter stop at observation and documentation.

As you watch, note which output shows overall boot phases and which identifies unit activation durations. Neither output alone proves the dependency path responsible for reaching a specific startup target. This leads to a third command.

3. Follow the time-critical dependency chain

systemd-analyze critical-chain displays a tree of units whose ordering influenced the displayed target. In the result, @ marks when a unit became active or began, while + marks its recorded activation duration. This is generally a better starting point than a raw longest-first list when identifying a dependency that delays a particular target. Nevertheless, systemd documents limitations when socket activation, parallelism or units with no activating phase are involved.

$ systemd-analyze critical-chain
multi-user.target @11.200s
└─example-app.service @10.200s +1.000s
  └─network-online.target @10.100s
    └─systemd-networkd-wait-online.service @2.100s +8.000s

Illustrative dependency-tree excerpt. The example-app.service line became active at 10.2 seconds in this artificial scenario and spent one second in activation. This chain suggests that reaching network-online.target influenced the target’s timing. It does not, by itself, prove a bug in networking, nor does it establish that every other application was ready at 11.2 seconds.

You can direct the analysis at a specific unit by providing its exact unit name, for example systemd-analyze critical-chain ssh.service on a system with such a unit. Many distributions use sshd.service instead; discover the installed unit name rather than guessing. For the networking context, revisit OSNTC.036 on network link discovery and Linux Command #60 — resolvectl.

Worked example — when the biggest number is not the bottleneck

Reported observation	Interpretation	Practical next step
A service appears first in blame	Its recorded activation lasted longer than other listed units.	Check whether the service appears on the critical path.
The same service appears in critical-chain	Its timing may be relevant to reaching the target.	Review ordering, dependencies and its own startup logs.
A slow service is absent from the target chain	It may have started in parallel or may not affect that target.	Avoid assuming its removal would shorten target time.
Kernel phase is long but userspace is short	Delay may occur before the systemd service manager has taken control.	Study early-boot hardware and kernel logs, not only service units.

Imagine a server reports a 14-second total startup. An optional logging service takes eight seconds but runs in parallel, while a network dependency blocks the application target for five seconds. The eight-second duration ranks highest in blame; however, fixing it may leave the target startup unchanged. First identify the actual target and critical chain, then validate the diagnosis through controlled measurements across comparable boots. The example numbers are hypothetical and are not benchmark data.

4. A second video — measured boot optimization in practice

The DevConf.US 2024 engineering session “Accelerating Linux Boot Time” discusses systemd-analyze within a broader process of measuring Linux startup, evaluating systemd ordering and examining kernel and initramfs contributions. The lecture provides useful professional context for why an accurate baseline comes before any optimization.

A high-quality measurement process records the distribution, kernel, init system version, boot target, storage and network conditions, cold-versus-warm boot status and whether services were intentionally disabled. Comparing different environments without those details can produce misleading conclusions.

5. Safe optional read-only follow-ups

• systemd-analyze plot > boot-timeline.svg writes an SVG timeline generated by the systemd tool. It is optional; no diagram is inserted into this published lesson.
• systemd-analyze --version reports the installed tool version, which can help explain differences between hosts.
• systemctl list-units --type=service shows loaded service-unit status; this is a separate, read-only command.
• journalctl -b reads logs from the current boot where access permits. Interpret log timestamps and time domains carefully before comparing them with other tools.

The SVG mentioned above is a built-in diagnostic artifact generated locally by systemd, not an original diagram provided as in-story media. Systemd offers additional verbs such as verify and security; these belong in focused lessons on unit-file validation and service hardening.

6. Avoid these common diagnostic errors

• Confusing blame with critical-path delay. Unit startup duration and impact on the final target are different measurements.
• Adding the target milestone to total boot time. The target timestamp is part of the sequence already reported.
• Comparing unlike systems. A VM, workstation and bare-metal production server can expose different phases or unit configurations.
• Assuming “boot complete” means every application is fully ready. Services may still initialize internal work after systemd considers them started.
• Disabling services because a tutorial suggests it. Removing network, storage, security or monitoring services can damage availability or visibility.

7. Practical laboratory assignment

Use a nonproduction Linux system with systemd, or study the illustrative examples above if no suitable machine is available. Do not change service configurations for this assignment.

• Record the distribution, systemd-analyze --version, boot target and hardware type.
• Run systemd-analyze time and record which startup phases are present. Do not invent missing measurements.
• Run systemd-analyze blame and write down the three largest recorded unit activation durations.
• Run systemd-analyze critical-chain and see whether the first blame service appears on the target chain.
• Write a three-sentence diagnosis separating observations, interpretations and the next check you would perform.

8. Knowledge check and answer key

• What does systemd-analyze time report?
• Does the first entry in blame always delay the final boot target the most?
• What is the meaning of @ and + in critical-chain output?
• Can an 8-second service start overlap another service’s initialization?
• Why should a technician avoid disabling a network or storage unit solely to improve its blame ranking?

Answers: (1) Recorded startup phase durations and selected target timing. (2) No; overlapping services and dependency ordering matter. (3) @ is the unit’s relevant activation timestamp, while + is its recorded start duration. (4) Yes, systemd commonly starts units in parallel. (5) The service may be required for normal operation, and the measurement does not prove it causes the observed delay.

9. Primary documentation and continued study

The governing reference is the official systemd-analyze manual. Practical supporting documentation includes ArchWiki’s boot-performance guide and Oracle Linux’s boot-time diagnostics discussion. Continue to What Is systemd? or Linux systemd timers for related concepts. The next main-rotation course after Linux is Windows Command, while additional specialty tracks—including OSHRE and OSPCB—remain active.

BitcoinVersus.Tech — Independent open-source technical education.

BitcoinVersus.Tech Editor’s Note: This lesson prioritizes safe, read-only Linux troubleshooting. If these free technical lessons are useful, support independent educational publishing with a donation of 5,000 satoshis. Scan the original QR code below with a compatible Bitcoin wallet and verify the Bitcoin address 3C9o19EH5HSiwEPyCTmEKzxhNCbo2X6TTb before sending.

Open the QR code on a separate screen and scan it with a Bitcoin wallet. BitcoinVersus.tech is not a financial advisor. This media platform reports on financial subjects purely for informational purposes.