Optimize Your Boot: Analysis with systemd-analyze

Modern Linux systems boot quickly thanks to systemd, but real-world performance may vary based on hardware, services, and configurations. The systemd-analyze tool provides deep insights into your boot sequence, revealing bottlenecks and suggesting optimizations. This extensive article explores every facet of systemd-analyze, from basic commands to advanced visualization and best practices.

1. Understanding the Systemd Boot Process

The boot procedure orchestrated by systemd includes:

• Firmware amp GRUB: Initializes hardware and loads the kernel.
• Kernel amp initrd: Probes modules, mounts root file system.
• systemd-init: Launches services in parallel, manages dependencies.
• Target Units: multi-user.target, graphical.target signal readiness for multi-user or graphical sessions.

2. Getting Started with systemd-analyze

Invoke the primary tool to see overall boot timings:

systemd-analyze

This prints three key metrics:

• Startup time (firmware kernel initrd).
• Loader time (GRUB delay).
• User space time (systemd service startup).

2.1 Blame: Identifying Slow Services

systemd-analyze blame

Lists services ordered by initialization time:

2.2 Critical Chain: Dependency Paths

systemd-analyze critical-chain

Shows a tree of units that block reaching a target:

graphical.target @4.500s
└─multi-user.target @4.500s
  └─network-online.target @3.200s  1.000s
    └─NetworkManager-wait-online.service @2.200s  1.000s
      └─NetworkManager.service @1.000s  1.200s
  

2.3 Plot: Graphical SVG

systemd-analyze plot gt boot.svg

Produces a scalable visualization. Open boot.svg in a browser to inspect overlaps and parallelization.

3. Interpreting Results

Key observations to make:

• Firmware vs. Userspace: If firmware time is high, consider BIOS updates.
• Long-Running Services: Identify services exceeding 500ms.
• Dependency Stalls: Services like NetworkManager-wait-online.service often block targets.
• Parallelization Gaps: Look for services that could run in parallel but are serialized by dependencies.

4. Practical Optimization Techniques

4.1 Mask or Disable Unused Services

• sudo systemctl disable bluetooth.service
• sudo systemctl mask cups.service (if no printing needed)

4.2 Optimize Network Dependencies

Replace NetworkManager-wait-online.service with network-online.target dependency only where necessary. Alternatively, configure services to start without waiting.

4.3 Leverage Socket Activation

Services like ssh.socket start sshd.service on-demand, reducing startup cost.

4.4 Tuning journald

• Edit /etc/systemd/journald.conf, set SystemMaxUse and Compress=yes.
• Rotate logs frequently to prevent disk I/O stalls.

5. Advanced Analysis

5.1 Bootchart Integration

Install systemd-bootchart to gather block I/O and CPU usage during boot:

sudo apt install systemd-bootchart
sudo systemctl enable systemd-bootchart

5.2 Flame Graphs for Deeper Insight

Generate flame graphs using Brendan Gregg’s toolkit for profiling libraries and kernel calls.

6. Case Study: Debian/Ubuntu Optimization

Initial boot time: 5.2s. After tuning:

Final boot time: 3.4s (35% improvement).

7. Best Practices and Automation

• Automate analysis: @reboot root /usr/bin/systemd-analyze blame gt /var/log/boot-blame.log.
• Use systemd.timer units to schedule periodic cleanup (tmpfiles-clean.timer).
• Pinpoint regressions after upgrades by comparing systemd-analyze logs over time.

8. Security amp Network Considerations

During system updates or remote optimizations, securing your connection is vital. Consider reputable VPN providers such as NordVPN, ProtonVPN, and ExpressVPN to encrypt traffic and protect against MITM attacks.

9. Resources amp Further Reading

• Official systemd Documentation
• ArchWiki: Systemd
• Flame Graphs by Brendan Gregg