You press the power button. You grab a coffee. You come back. Your Linux system is still loading. That lag adds up. For system administrators managing servers or developers iterating on workstations, every second of boot time is wasted potential. You need a method to find exactly what is slowing down your startup and fix it. That is where systemd-analyze comes in. This built-in tool gives you a detailed timeline of your boot process. In this guide, you will learn how to use it to profile your system, identify problem services, and apply targeted fixes to reduce boot time on Linux with systemd-analyze.
To reduce boot time on Linux with systemd-analyze, start by running `systemd-analyze blame` to see which services take the longest. Disable or mask unnecessary services like bluetooth or avahi. Use `systemd-analyze critical-chain` to find dependencies that block the boot sequence. Then apply changes one at a time and re-profile. Even a 10-second improvement on a server farm translates to significant uptime gains.
Profiling your boot with systemd-analyze
Before you can fix a slow boot, you need a clear picture of what is happening. The systemd-analyze command provides several subcommands that act like a debugger for your startup sequence.
Start with the basic timing report. Open a terminal and run:
systemd-analyze
This prints the total time the firmware, kernel, and userspace took to load. It gives you a high-level benchmark. For example, you might see something like:
Startup finished in 3.452s (firmware) + 4.231s (kernel) + 15.892s (userspace) = 23.575s
That 15 seconds in userspace is where you will find the most room for improvement. The firmware and kernel times depend on your hardware and BIOS settings, but userspace is controlled by your systemd services.
To get a more detailed breakdown, use the blame subcommand:
systemd-analyze blame
This lists every service that ran during boot, sorted by the time it took to initialize. The output looks like a ranked list of culprits. A typical result might show NetworkManager-wait-online.service taking 6 seconds or postfix.service holding up the process.
Here is a practical process to follow:
- Run
systemd-analyze blameand note the top five services. - Check if any of those services are unnecessary for your workflow.
- For each service, decide to disable, mask, or optimize it.
- Reboot and run
systemd-analyzeagain to measure the effect. - Repeat until you are satisfied with the boot time.
Identifying the critical chain
The blame command shows individual service times, but it does not show dependencies. A service might be fast on its own, but if it waits on a slow parent service, the boot still lags. For that, use the critical-chain subcommand:
systemd-analyze critical-chain
This highlights the longest path of dependencies from the target to the kernel. It shows you the bottleneck in your boot sequence. For example, if graphical.target depends on multi-user.target, which depends on network-online.target, and that waits for NetworkManager-wait-online.service, you see a chain of delays.
You can also use systemd-analyze plot > boot.svg to generate a visual timeline. Open the SVG file in a browser to see a Gantt chart of your boot. This makes it easier to spot overlapping services that could be parallelized.
Common services that slow down boot
Some services are notorious for adding seconds to the startup. Here is a table of typical offenders and how to handle them:
| Service | Typical delay | Action |
|---|---|---|
| NetworkManager-wait-online.service | 5 to 10 seconds | Disable if not needed |
| postfix.service | 3 to 5 seconds | Disable or mask |
| avahi-daemon.service | 2 to 4 seconds | Disable if no mDNS needed |
| bluetooth.service | 2 to 3 seconds | Disable on servers |
| systemd-journal-flush.service | 1 to 3 seconds | Set Storage=volatile in journald.conf |
| plymouth-quit-wait.service | 2 to 4 seconds | Disable plymouth on servers |
To disable a service, run:
sudo systemctl disable <service-name>
To mask it completely (prevents any activation), run:
sudo systemctl mask <service-name>
Be careful with masking. Only do it for services you are certain you will never need.
Optimizing services instead of disabling them
Not every slow service can be removed. Some are essential. In those cases, you can optimize their configuration to reduce boot time on Linux with systemd-analyze insights.
For example, NetworkManager-wait-online.service waits for the network to be fully up before allowing other services to start. If your system does not require network connectivity at boot, you can disable this service without breaking network functionality later. Alternatively, set TimeoutStartSec=5 in the service override to cap the wait time.
Another common optimization is to adjust the journal flush behavior. By default, systemd journals are stored in memory during boot and flushed to disk later. This flush can take time. Edit /etc/systemd/journald.conf and set:
Storage=volatile
This keeps journals in RAM, reducing disk I/O during boot. Be aware that logs will be lost on reboot unless you configure a persistent journal with a different mechanism.
You can also reduce boot time by trimming unnecessary kernel modules. If your system does not use FireWire hardware, for example, you can blacklist the firewire kernel module. This prevents the kernel from probing for FireWire devices at startup. For guidance on this, see our guide on
Using drop-ins for service overrides
Directly editing service files is risky. Updates can overwrite your changes. Instead, use drop-in files. Create a directory for the service under /etc/systemd/system/<service-name>.service.d/ and place a .conf file there.
For example, to add a timeout to NetworkManager-wait-online.service:
sudo mkdir -p /etc/systemd/system/NetworkManager-wait-online.service.d/
sudo nano /etc/systemd/system/NetworkManager-wait-online.service.d/timeout.conf
Add these lines:
[Service]
TimeoutStartSec=5
Then reload systemd:
sudo systemctl daemon-reload
This method keeps your changes isolated and survives package updates.
Mistakes to avoid when reducing boot time
Tuning boot time is satisfying, but it is easy to break something. Here are common mistakes to watch for:
- Disabling essential services without testing. If you disable
systemd-logind.service, your desktop environment may fail to start. - Masking services that are dependencies for other services. Always check dependencies with
systemctl list-dependencies <service>. - Making too many changes at once. Apply one change, reboot, and measure. Otherwise, you will not know which change caused a problem.
- Ignoring the firmware and kernel stages. While this guide focuses on userspace, you can also speed up the firmware stage by disabling unnecessary boot devices in your BIOS.
Expert advice: Do not optimize for the sake of optimization. A 30-second boot is perfectly fine for a workstation. Focus on improvement only if the current time causes real friction. On servers, measure boot time in context of deployment and recovery scenarios.
Measuring the impact of your changes
After each change, reboot and run systemd-analyze again. Compare the total time to your baseline. You can also use systemd-analyze blame to see if the targeted service improved.
For a more granular view, use systemd-analyze time to see the breakdown per phase. If you notice the kernel time is still high, consider tuning kernel parameters or updating to a newer kernel. The kernel stage is heavily influenced by hardware probing and module loading.
If you are managing multiple systems, consider automating the profiling with a script that runs systemd-analyze and logs the output. This helps track regressions after updates.
When to look beyond systemd-analyze
Systemd-analyze is powerful, but it only covers the init system. Some boot delays happen before systemd starts. For example, the BIOS or UEFI firmware might take 10 seconds to initialize hardware. In that case, you need to adjust firmware settings, not systemd.
Also, if your boot time is dominated by kernel module loading, you might benefit from building a custom kernel with only the modules you need. This is an advanced technique, but it can shave seconds off the kernel stage. For a deeper look at kernel optimization, see
Another area is storage. If you are using a traditional hard drive, upgrading to an SSD will reduce boot time more than any software tweak. For systems with SSDs, check that your filesystem is mounted with the noatime option to reduce write operations.
Putting it all together for a faster boot
Reducing boot time on Linux is a systematic process. Start by profiling with systemd-analyze blame and critical-chain. Identify the top three services that add the most delay. For each one, decide whether to disable, mask, or optimize it. Apply changes one at a time using drop-in files. Reboot and measure the effect. Repeat until you reach your target.
This approach works on any distribution that uses systemd, including Fedora, Ubuntu, and Arch. The same commands apply across the board. The only difference is the default set of services.
If you are troubleshooting boot issues beyond performance, such as failures or hangs, check out our guide on It covers using journalctl -b to read boot logs and find errors.
A faster boot means a more responsive system
Every second you save on boot time is a second you get back for actual work. For a sysadmin managing a hundred servers, a 10-second improvement per server saves over 15 minutes per reboot cycle. For a developer, a snappy boot means less context switching and more time writing code.
The tools are already on your system. You do not need third-party software or complex scripts. Just systemd-analyze and a willingness to test. Start with the blame command today. See what is holding your system back. Then apply the changes we discussed. Your future self, waiting for that login prompt, will thank you.
