Table of Contents
Understanding Boot Performance
Boot performance focuses on how fast (and reliably) a system goes from power-on to a usable login prompt or desktop. In this chapter, you’ll learn how to:
- Understand the major stages of the Linux boot process that affect timing
- Measure boot time and find slow components
- Use
systemdtools to analyze and improve boot performance
Low boot time is not just for desktops and laptops; on servers, slow boot can delay maintenance windows and lengthen recovery times after outages.
This chapter assumes you already understand basic systemd concepts and log viewing from earlier chapters in this part.
Key Boot Stages That Impact Performance
Without re-teaching the entire boot process, it’s useful to know which stages typically matter for performance tuning:
- Firmware (BIOS/UEFI)
- Hardware initialization and self‑tests
- Disk/boot device enumeration
- Bootloader selection
- Bootloader (e.g., GRUB2)
- Menu display and timeout
- Loading kernel and
initramfs - Kernel + initramfs
- Hardware/driver initialization
- Root filesystem discovery and mounting
- Switching from
initramfsto real root - Init system (
systemd) - Starting essential system services
- Activating sockets, devices, mounts, targets
- Reaching multi‑user or graphical targets
Most of your tuning effort in a modern Linux system focuses on:
systemdservice startup- Filesystem and device mount times
- Network initialization
- Any custom or third‑party services
Firmware and kernel-level improvements are possible but more limited.
Measuring Boot Time
Before optimizing, measure where time is spent. On systemd-based systems, the main tools are:
systemd-analyzesystemd-analyze blamesystemd-analyze critical-chainjournalctlwith boot filters
Total Boot Time with `systemd-analyze`
Run:
systemd-analyzeExample output:
Startup finished in 3.150s (firmware) + 1.982s (loader) + 4.687s (kernel) + 12.345s (userspace) = 22.164s
graphical.target reached after 12.100s in userspace.Interpretation:
firmware: Time spent in BIOS/UEFIloader: Bootloader time (e.g., GRUB menu timeout)kernel: From kernel start untilsystemdbegins userspaceuserspace: Fromsystemdstart until default target (e.g.,graphical.target) is reached
Actionable parts for a typical admin:
- Reduce bootloader delays (menu timeouts)
- Reduce userspace time (service tuning, parallelization, dependencies)
Measuring Per-Service Time: `systemd-analyze blame`
Run:
systemd-analyze blameExample:
10.222s NetworkManager-wait-online.service
5.023s docker.service
3.112s snapd.service
1.701s plymouth-quit-wait.service
1.320s dev-sda2.device
...This shows how long each unit took to start. Look for:
- Services with unusually high times
- Services that might be optional on your system
Note: blame is approximate and does not show dependency relationships, only durations.
Visualizing the Critical Path: `systemd-analyze critical-chain`
Run:
systemd-analyze critical-chainExample (abridged):
graphical.target @12.100s
└─multi-user.target @12.099s
└─network-online.target @12.098s
└─NetworkManager-wait-online.service @1.876s +10.222s
└─NetworkManager.service @0.800s +1.075s
└─basic.target @0.750s
└─sockets.target @0.749s
└─snapd.socket @0.740s +5ms
...Interpretation:
- Shows the dependency chain that determines when key targets are reached
- For each unit:
@timewhen it started,+durationhow long it ran - Lets you see which long-running services are actually blocking the boot
Use critical-chain to focus on items that are on the critical path rather than just “slow in isolation.”
Boot Charts and Graphs
Many distributions support a graphical view:
systemd-analyze plot > boot.svg
Open boot.svg in a browser or image viewer.
- Horizontal axis: time since boot start
- Each service: bar showing when it started/finished
- Useful to see overlap and idle gaps
This helps identify:
- Services that could start in parallel
- Large idle gaps before certain services begin
- Services starting unnecessarily early
Using Logs to Investigate Slow Boots
System logs provide timing and error context beyond systemd-analyze.
Viewing Logs for the Current Boot
Use:
journalctl -bThis shows logs starting from the current boot. To focus on boot timing:
journalctl -b -g "Started "
journalctl -b -p warning- Look for services with long delays between “Starting …” and “Started …”
- Look for warnings/errors about timeouts, failed mounts, or hardware problems
Viewing Logs for Previous Boots
Each boot has an index:
journalctl --list-bootsExample:
-1 1f2e3d4c5b6a4e3d8c9f0a1b2c3d4e5f Mon 2025-11-03 10:00:00 UTC—Mon 2025-11-03 10:05:00 UTC
0 a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6 Mon 2025-11-03 15:15:00 UTC—Mon 2025-11-03 15:18:00 UTCThen:
journalctl -b -1This is useful if users report “sometimes the system boots very slowly” — you can compare logs from a slow boot to a normal one.
Common Boot Bottlenecks
Boot slowdowns often fall into recurring categories. Here are the main ones and how to spot them.
Network Initialization Delays
One of the most frequent causes of slow boot is waiting for network connectivity.
Typical symptoms:
systemd-analyze blameshows long times for:NetworkManager-wait-online.servicesystemd-networkd-wait-online.servicecritical-chainshowsnetwork-online.targeton the critical path
These units block further services until the network is “up.” On servers, this might be necessary; on desktops or laptops, it often isn’t.
Options to Improve
- Disable “wait-online” if not required:
sudo systemctl disable NetworkManager-wait-online.service
# or
sudo systemctl mask NetworkManager-wait-online.serviceOnly do this if no critical services depend on the network being fully online at boot.
- Adjust timeouts in network config (distribution-specific) to shorter values.
- For headless servers, ensure network config is correct so it does not fall back to long DHCP timeouts.
Always test changes with:
sudo systemctl reboot
systemd-analyze
systemd-analyze critical-chainFilesystem and Mount Issues
Another common delay: the system waits for filesystems or network shares that are slow or unavailable.
Symptoms:
systemd-analyze blameshows large times for:local-fs.targetorremote-fs.target- Specific mount units, e.g.,
mnt-backup.mount - Logs show repeated messages like:
A start job is running for /mnt/backup (1min 30s / 1min 30s)- Mount timeouts or “dependency failed” errors
To investigate:
systemctl list-units --type=mount
journalctl -b -u mnt-backup.mountWays to improve:
- Remove or comment out obsolete entries in
/etc/fstab - For optional or occasionally-present devices, mount them with:
noautoornofailoptionsx-systemd.device-timeout=…to reduce waiting time- For network filesystems (NFS, CIFS), consider:
x-systemd.automountso mounting is deferred until first use- Reasonable timeouts and
bg(background) options where appropriate
Example /etc/fstab entry with systemd options:
server:/export /mnt/nfs nfs defaults,noauto,x-systemd.automount,x-systemd.device-timeout=10 0 0This prevents the entire boot from being stalled by a slow NFS server.
Graphical Boot and Display Managers
Display managers and graphical stacks can add noticeable time.
Symptoms:
gdm.service,lightdm.service,sddm.service, etc., appear high inblamegraphical.targetis reached significantly later thanmulti-user.target
Options:
- For systems that do not need a GUI:
- Disable graphical target and use multi-user (text-only) boot:
sudo systemctl set-default multi-user.target- For systems with a GUI:
- Ensure the display manager is appropriate for your hardware (lighter options can be faster)
- Disable unnecessary GUI autostart applications at the desktop environment level (not part of
systemdboot, but affects perceived usability after login)
Hardware Probing and Firmware
Some delays are outside the OS’s direct control:
- Long BIOS/UEFI POST
- RAID controller initialization
- Disk spin-up on older or external drives
- USB device enumeration
You usually see these in systemd-analyze as large firmware or kernel times.
Limited options:
- In firmware settings:
- Disable long diagnostics (e.g., network PXE boot scans you don’t need)
- Reorder boot devices
- On Linux:
- Avoid scanning non-existent devices
- For some storage, you can tune power management or hotplug settings
Third-Party and Optional Services
Applications that install their own system services can slow boot.
Identify:
- Review the slowest units from
systemd-analyze blame - Check which are truly required at boot and which are only needed on demand (e.g., Docker, virtualization daemons, printing on a server, some cloud agents)
Adjust:
- Disable non-essential services:
sudo systemctl disable SERVICE_NAME
# or
sudo systemctl mask SERVICE_NAME- Consider socket or path activation where supported (starts only when first used).
Always confirm you are not disabling something essential. Test by rebooting and verifying system functionality.
Tuning Systemd Startup Behavior
systemd offers several mechanisms that influence boot performance.
Parallelization and Dependencies
By default, systemd runs units in parallel as long as dependencies allow it. Unnecessary dependencies can serialize startup and slow things down.
To analyze dependencies for a unit:
systemctl list-dependencies NAME.service
systemctl list-dependencies --reverse NAME.serviceLook for:
- Services that have
Requires=orAfter=relationships that might not be needed - Units that depend on
network-online.targetwhennetwork.targetwould be enough
You can override dependencies without editing the original unit files by using drop-ins.
Using Drop-in Overrides
To modify a unit safely:
sudo systemctl edit NAME.serviceThis opens an editor with a fragment like:
[Service]
# Your overrides hereOr to adjust dependencies:
[Unit]
After=network.target
Wants=network.target
# Remove network-online.target if not needed:
# After=
# Wants=Save and reload:
sudo systemctl daemon-reloadThen reboot and re-measure. Be conservative: incorrect dependency changes can cause services to start before their requirements are truly ready.
Service Timeouts
Some services might wait a long time when something goes wrong. You can tune or cap this behavior.
For a specific unit:
- Check its configured timeout:
systemctl show NAME.service -p TimeoutStartUSec- Override it with a drop-in:
sudo systemctl edit NAME.serviceExample:
[Service]
TimeoutStartSec=30
This ensures that if the service cannot start within 30 seconds, systemd moves on. Make sure the service can tolerate being stopped or failed earlier.
Delayed or On-Demand Services
Some services do not need to start at boot; they can be activated when first used.
- Socket-activated services: start when a connection is made to a socket
- Path-activated services: start when a file/directory changes
- Automounts: start when a filesystem is first accessed
Typical usage depends on their unit definitions and your distribution; I/O-heavy or rarely used daemons are good candidates to be started on demand.
Reducing Perceived Boot Time
Perceived boot time is “how long until the system feels ready to use,” which is slightly different from measured boot completion.
Ways to improve user perception:
- If running a desktop:
- Disable non-essential applications set to auto-start after login
- Use lighter desktop environments or window managers when suitable
- Use fast storage for root filesystem (SSD vs HDD)
- Ensure swap configuration doesn’t cause early heavy swapping
- Avoid running large tasks immediately at boot; schedule them later (e.g., with timers instead of “run at boot” scripts)
Even if systemd reports 20 seconds to graphical.target, users may not notice if the system is responsive quickly after the login screen.
Monitoring Boot Performance Over Time
Once tuned, keep an eye on boot speed so regressions don’t go unnoticed.
Ideas:
- Periodically record
systemd-analyzeresults, for example:
systemd-analyze >> /var/log/boot-times.logvia a simple root cron job or systemd timer.
- Watch for:
- Incremental increases in
userspacetime - New long-running services after software installs or updates
- Use
journalctl --list-bootsandsystemd-analyze blameif boot slows suddenly, especially after big updates.
This is especially important on critical servers where boot time matters during maintenance windows or failover scenarios.
Practical Boot Tuning Workflow
A typical sequence for improving boot performance:
- Measure baseline
systemd-analyzesystemd-analyze blamesystemd-analyze critical-chain- Identify obvious bottlenecks
- Network “wait-online” services
- Slow mounts or failing devices
- Bulky third‑party services
- Review logs
journalctl -bfor timeouts, errors, and long gaps- Apply targeted changes
- Disable/mask unnecessary services
- Fix or mark optional mounts
- Adjust timeouts or dependencies with drop-ins
- (If needed) tweak bootloader timeouts or firmware settings
- Reboot and validate
- Confirm system functions as required
- Re-run
systemd-analyzeand compare - Monitor for a few cycles to ensure stability
Working iteratively like this avoids breaking dependencies and keeps changes auditable.
By understanding where time is spent and using systemd’s analysis tools, you can systematically improve both real and perceived boot performance, making systems more responsive and reducing downtime after reboots.