Slow Linux Boot? Use systemd-analyze to Trace and Optimize Immediately – ITFROMZERO

Table of Contents

The Problem: Why is Your Server Booting Slowly?

Have you ever typed the reboot command and finished making a cup of coffee only to find the server still hasn’t come back up? For a beginner, this waiting game often comes with anxiety, wondering where the system is “stuck.” On the Ubuntu 22.04 VPS I manage, the initial boot time took nearly 120 seconds. After just a few diagnostic steps using systemd-analyze, I brought that number down to 25 seconds.

Modern Linux distributions use systemd to start processes in parallel. While this method is very fast, it can also cause conflicts between service dependencies, creating frustrating bottlenecks. This article will help you peel back the layers of the boot process to find exactly what is wasting your time.

Understanding the systemd-analyze Helper

systemd-analyze is an incredibly useful built-in tool. It collects data from the moment the kernel starts running until the entire user-level environment (userspace) is ready.

Don’t rely on guesswork or gut feeling. This tool provides precise metrics down to the millisecond via 4 core commands:

time: A quick summary of the boot time.
blame: Ranks services from “slowest” to “fastest.”
critical-chain: Reveals the chain of services directly dragging down boot speed.
plot: Exports an SVG chart for a visual overview of the entire process.

Hands-on: Finding and Eliminating Bottlenecks

Step 1: Check Total Boot Time

First, get a general figure to serve as a benchmark. Simply open your terminal and run:

systemd-analyze

The output usually looks like this:

Startup finished in 3.452s (kernel) + 12.120s (userspace) = 15.572s 
graphical.target reached after 12.110s in userspace

Focus on the userspace section. While kernel time depends heavily on hardware, userspace is where you can fully optimize via software.

Step 2: Identifying Time-Consuming Services

To find out which services are hogging resources the longest, use the blame command:

systemd-analyze blame

On my actual server, network-manager-wait-online.service once wasted up to 10 seconds. Another service, plymouth-quit-wait.service, is also frequently at the top of the list.

Note: Don’t rush to disable the top services immediately. Sometimes service A is slow because it’s waiting for service B to respond. This is where deeper analysis is needed.

Step 3: Analyzing the Critical Chain

The critical-chain command helps you see the cause-and-effect relationship between processes:

systemd-analyze critical-chain

The results are displayed in a tree format. Services after the @ character indicate when they started running. If one link in this chain is slow, it creates a domino effect that extends the entire boot process.

Step 4: Visualization with Charts

If the terminal output is too hard to read, export it to an SVG image file to view in a browser:

systemd-analyze plot > boot_analysis.svg

Open this file with Chrome or Firefox, and you’ll see horizontal bars of varying lengths. The longer the bar, the more “attention” that service requires.

Step 5: Practical Optimization Tactics

Based on my personal experience, I usually apply these three solutions:

Aggressively disable unnecessary services: Does your server need Bluetooth or a Modem? Disable ModemManager.service or bluetooth.service immediately.
```
sudo systemctl disable bluetooth.service
```
Handle the Network Manager “black hole”: network-manager-wait-online often waits for the network to connect before allowing the boot process to continue. If your server uses a static IP and you don’t strictly require network connectivity in the very first second, use the mask command:
```
sudo systemctl mask network-manager-wait-online.service
```
Clean up LVM/RAID: Many distributions scan for LVM drives by default during boot. If you’re only using standard ext4 partitions, disabling these services can save you about 2-3 precious seconds.

Sweet Results

After fine-tuning, I ran the check again and got a surprising result:

Startup finished in 3.102s (kernel) + 4.220s (userspace) = 7.322s

Userspace time dropped from 12 seconds to just over 4 seconds—three times faster. The server is noticeably more responsive whenever I need to perform maintenance or reboot remotely.

Optimizing boot isn’t just about speed; it’s a great way to gain a deeper understanding of the operating system you’re running. Don’t be afraid to experiment with systemd. However, remember to double-check a service’s function before using disable to avoid unfortunate server connection issues!