systemd-analyze: Measure Boot Time, Trace Dependencies, and Audit Unit Files

If you manage Linux systems with systemd, you already know the usual trio: systemctl, journalctl, and a vague sense that “boot feels slow.”

systemd-analyze is the tool that turns that vague sense into numbers, graphs, and actionable clues. It can:

• break down where boot time goes
• show the time-critical dependency chain (what’s actually holding things up)
• generate an SVG timeline you can eyeball
• verify unit files for common mistakes
• audit a service’s systemd hardening posture

(If you run it with no arguments, it behaves like systemd-analyze time.)

Quick start

These five commands cover 90% of real-world use:

Let’s break down what each gives you, and how to interpret it.

1) Get the high-level boot time

This reports total time split into phases such as firmware/loader/kernel/userspace (the exact breakdown depends on platform and distro).

How to use it:

• If userspace is dominant, you’re likely looking at service ordering, slow mounts, network waits, or device timeouts.
• If kernel time is dominant, you’re looking at drivers/initramfs/hardware.

Tip: run it a few times across reboots. One slow boot can be “noise” (fsck, transient DHCP delay, etc.).

2) Find what’s blocking progress with critical-chain

This prints a tree of the time-critical chain—the units that form the effective “critical path” for reaching your default target. It’s often more useful than blame because it focuses on what gates the boot.

What to look for:

• Units that start late and have long +… durations
• Obvious “wait points” like:
  • network-online.target
  • slow mount units (especially remote/NFS)
  • storage discovery services

If you only change one thing, start here.

3) Use blame carefully

This lists units sorted by “startup duration.” It’s tempting to treat the top entry as the problem—don’t.

Why it can mislead:

• systemd starts lots of units in parallel
• some units appear slow but they’re not on the critical path
• socket activation and dependency ordering can skew what “took time” means

A good workflow:

1. Use critical-chain to find blockers.
2. Use blame to find “heavy” units worth investigating.
3. Confirm with logs (journalctl -b) before making changes.

4) Make boot performance visible with an SVG timeline

Open boot.svg in a browser and you’ll get a Gantt-style timeline showing when units started and how long they took.

What makes this valuable:

• you can see long gaps (e.g., network waits)
• you can see concurrency (what overlaps vs. what serializes)
• you can spot units starting much earlier/later than expected

If you’re troubleshooting with a team, the SVG is also the easiest artifact to share.

5) Graph dependencies with dot (Graphviz)

If you want to visualize service dependencies beyond the boot timeline, generate a Graphviz “dot” graph:

This is especially helpful when you suspect a unit has picked up unexpected ordering constraints via Wants=, Requires=, After=, Before=, mount dependencies, or target wiring.

6) Verify unit files before (or after) changes

When you edit or add unit files, systemd-analyze verify can catch common issues early:

This checks syntax and flags many configuration problems. It’s not a full semantic proof, but it’s an excellent “lint pass” before you restart services on production.

7) Audit systemd hardening with systemd-analyze security

Systemd includes a large set of sandboxing/hardening directives (namespaces, syscall filtering, capability bounding, filesystem protections, etc.).

systemd-analyze security summarizes how much of that is being used by a service and gives an exposure score (lower is better):

How to use it well:

• Treat it as a prioritization tool, not a verdict on the application.
• Use it to find “low-hanging fruit” services where you can safely add constraints.

A practical approach:

1. Pick a service with a high exposure score.
2. Add a small, safe hardening set (examples: NoNewPrivileges=yes, PrivateTmp=yes, ProtectSystem=strict, ProtectHome=yes, PrivateDevices=yes).
3. Restart and validate behavior.
4. Iterate toward tighter sandboxing.

Other handy subcommands you’ll actually use

Depending on your distro/systemd version, systemd-analyze includes a bunch of utilities beyond boot timing.

A few that come up often:

• systemd-analyze unit-paths – show where systemd looks for units
• systemd-analyze unit-files – list unit files and enablement state
• systemd-analyze cat-config – show the effective config after drop-ins/overrides
• systemd-analyze compare-versions – compare version strings (handy in scripts)
• systemd-analyze calendar / timespan / timestamp – parse and normalize systemd time formats
• systemd-analyze syscall-filter / capability – inspect sandbox primitives

If you’re exploring, run:

A repeatable workflow for “this host boots slowly”

1. Get a baseline
   
   systemd-analyze time

   1 2	systemd-analyze time

2. Find the actual blockers
   
   systemd-analyze critical-chain

   1 2	systemd-analyze critical-chain

3. Generate a boot timeline for visual confirmation
   
   systemd-analyze plot > boot.svg

   1 2	systemd-analyze plot > boot.svg

4. Check heavy units (but don’t assume they’re the cause)
   
   systemd-analyze blame | head -50

   1 2	systemd-analyze blame | head -50

5. Fix root causes carefully
   • remove unnecessary services from boot
   • avoid network-online.target unless you truly need it
   • convert “wait at boot” behaviors into timers where possible
   • consider socket activation for on-demand daemons
6. Validate unit edits
   
   systemd-analyze verify /etc/systemd/system/*.service

   1 2	systemd-analyze verify /etc/systemd/system/*.service

Closing thoughts

systemd-analyze is one of those tools that’s easy to ignore until you need it—and then it becomes indispensable.

If you keep a short checklist in your runbook, make it this:

• time for the headline number
• critical-chain for the true critical path
• plot when you need to see what’s going on
• verify before you ship unit file changes
• security to steadily harden long-running services