Boot profiling with systemd-analyze in Linux

If you've ever thought that your Linux It takes "half a lifetime" to start up, or you're simply curious to know what happens from the moment you press the power button until you see your desktop, systemd-analyze is the perfect tool to snoop on your system's startup.You don't need to be a professional system administrator to take advantage of it: with a few commands and some common sense you can understand what's happening and, if necessary, shave several seconds off the start time.

In many forums and communities, people share their start times as if they were sports records, but beyond the friendly competition, Measuring and understanding the boot process with systemd-analyze is useful for detecting failures, misconfigured services, and bottlenecks.Let's take a closer look at what this tool offers, how to interpret its results, and what changes make sense to optimize the startup without breaking anything important.

What is systemd-analyze and why should you care?

systemd-analyze is a utility included in systemd that is used to analyze boot performance in GNU/Linux systems.It is used by distributions such as Debian, Ubuntu, Fedora, openSUSE, Arch, Manjaro and many others, as long as systemd is the init system.

With this tool you can View both a global overview of boot time and a very fine breakdown by services, devices, sockets, and mounting points.In addition, it allows you to generate graphs in SVG format, view critical dependency chains, and obtain data in other formats such as JSON or tables.

Although systemd-analyze has quite a few options, For most users, a few commands are key: time, blame, critical-chain, and plotFrom there you can decide which services to review, which units to disable, and which problems to investigate more thoroughly.

Quick overview of the boot process on a Linux PC

Before we start looking at numbers, it's helpful to have a general idea of the phases of a computer's startup until systemd comes into playThis greatly helps in interpreting what portion of time corresponds to the kernel, the initrd, or user space, which systemd-analyze will show you.

The first is the physical ignitionThe power supply converts alternating current into suitable direct current, and the motherboard distributes voltages and amperages among the CPU, RAM, hard drives, etc. Then the famous firmware, either the BIOS classic or modern UEFI, which lives in a ROM on the board.

In this firmware phase, the following is executed: POST (Power On Self Test), which checks memory, keyboard, controllers, disks, and other basic devicesFurthermore, that's where the decision is made. boot order: disc, USBDVD, network, etc. The "customizable" configuration is saved in a small CMOS memory powered by the motherboard's button cell battery.

Once the boot device is detected, the firmware looks for the boot sector (MBR or EFI partition) and hands control over to the boot manager, which in Linux is usually GRUBGRUB loads its configuration (usually from /boot/grub/grub.cfg), displays the menu (boot menu timeout) and, when you choose system and kernel, the next phase starts.

At that moment the boot manager loads the kernel image (vmlinuz) and the initial boot environment, the initramfs, which contains a "mini-Linux" with what is needed to detect disks, modules and the root file systemThat image is loaded into RAM, mounts the final root, and finally executes the init process with PID 1.

Today, in most distribution systems, PID 1 is occupied by systemd, which is responsible for starting services, mounting file systems, preparing the user environment and, ultimately, launching the Display Manager and the desktop.It is precisely this part, from when systemd starts until the system is "usable", that we can measure in considerable detail thanks to systemd-analyze.

systemd-analyze time: the total boot time

El simpler command And the one that is usually used first is simply:

Run: systemd-analyze

You can also use:

Output example:
Startup finished in 0.912s (kernel) + 0.731s (initrd) + 1.485s (userspace) = 3.129s

With this summary, You can directly see how long the kernel takes, how long the initrd takes, and how long the user space portion managed by systemd takes.In some distributions (for example, certain Debian/Ubuntu) initrd does not appear separately and its timing is added to the kernel.

This general data serves as a reference and for comparison after making changes. It's quite common to see systems with older HDD drives that move between 20 and 60 seconds, and systems with SSD modern ones that take around 3-10 seconds, always depending on how many services are loaded.

systemd-analyze blame: who is delaying the startup

When we want to go into detail, the next logical step is

Command: systemd-analyze blame

With this command, systemd-analyze displays a list of all units (services, mounts, devices, sockets) sorted from longest to shortest initialization timeSomething like:

5.678s NetworkManager-wait-online.service
3.210s dev-sda1.device
2.345s snapd.service
...

This list is invaluable for detecting what's "stealing" seconds. Now then, Care must be taken when interpreting the result, because a service may appear slow simply because it depends on another service that takes time to be ready.The culprit is not always the one who has the most seconds ahead of them.

Quick filtering: If you only want to see the worst ones, you can combine it with filtering tools, for example:

Example: systemd-analyze blame | head

or in some guides it's written inline as "systemd-analyze blame | head -n 10". In any case, The usual approach is to review the initial elements and ask yourself if you really need them to be active or if there are less resource-intensive alternatives..

systemd-analyze critical-chain: the critical startup chain

Another very interesting view is the critical chain, which is obtained with:

Command: systemd-analyze critical-chain

The exit is presented as a tree in which It shows which units form the slowest path to the main objective (by default the graphic or multi-user target), showing for each how long it takes and when it starts. For example: uterine

graphical.target @12.345s
└─multi-user.target @12.345s
└─NetworkManager-wait-online.service @7.000s +5.345s
└─NetworkManager.service @2.000s +1.234s
...

In this type of exit, The time that appears after "@" indicates when the unit has been reached, and the one that follows "+" is the duration of its startup.Again, it should be remembered that due to dependencies and parallel execution, some figures may appear somewhat misleading at first glance.

Additionally, there is the option to call critical-chain by specifying a particular unit, for example:

systemd-analyze critical-chain NetworkManager.service

With this, You get the critical chain related to that specific unit, useful when you're investigating delays in a specific service..

systemd-analyze plot: SVG graph of the boot process

If you prefer something more visual, you can generate an SVG graphic with:

Example: systemd-analyze plot > boot_analysis.svg

or similar names such as imagen.svg, arranque.svg o 0-graficocarga.svg. The generated SVG file contains a bar chart representing the time it takes for each unit to start, also showing overlaps and dependencies..

You can open this chart with a vector graphics editor like Inkscape, with GIMP or simply with a Web navigator modernIt is especially useful for understanding at a glance which part of the startup is most congested and where there might be room to run things in parallel.

List enabled services and other related tools

In addition to systemd-analyze, It is common to supplement the analysis using systemctl to list the enabled units and their status. For example: uterine

Example: systemctl list-unit-files --state=enabled

Example: systemctl list-unit-files --type=service | grep enabled

Thus, You can locate services you don't use (for example, ModemManager, Bluetooth if you don't use it, email services like Postfix, etc.) and consider disabling them..

Common commands:

• Disable a service so that it does not start with the system:
  systemctl disable nombre.service
• Re-enable it on startup:
  systemctl enable nombre.service
• Stop it in the current session:
  systemctl stop nombre.service
• Start it manually:
  systemctl start nombre.service
• To mask it in order to prevent it from starting in any way:
  systemctl mask nombre.service

In graphical environments there are also tools such as systemadm (systemd System Manager, from the systemd-ui package), the systemd-kcm module for KDE Plasma, or the YaST service manager in openSUSEThey allow you to view the status of the units and activate or deactivate services without touching the console.

View messages and errors during startup

Beyond systemd-analyze, it's useful to know that During startup you can hide the graphical "splash" and view the messages in text by pressing the down arrow keyThere you'll usually see lines with "OK" in green and, if something goes wrong, "FAILED" messages or warnings with time counters.

Typical messages:

Example:
A start job is running for wicked managed network interfaces (x s / no limit)
A start job is running for ModemManager.service (x s / 1min 30s)

indicate that systemd is waiting for a drive to finish booting or reach a certain state, which can cause considerable delays.The usual thing to do is then to search for the name of that unit using systemd-analyze and systemctl to see what's going on.

Consultation: Once the system has started, you can check the log of the last session with:

Example: journalctl -b

and so View errors, warnings, or abnormal times related to specific services.

Real-world examples of startup optimization

In practice, some users have gone from startup times close to a minute or even more than 40 seconds to very reasonable figures after a few adjustments. On systems with HDDs, the time has been reduced from 40+ seconds to about 18 seconds simply by disabling unnecessary services and adjusting network management..

Actions that have helped: Some real-world examples of actions that have helped improve times like "Boot completed in 880ms (kernel) + 750ms (initrd) + 1.148s (user space) = 2.780s" are:

• Disable NetworkManager-wait-online.service when no services that depend on the network from the start are needed.preventing the system from waiting for connectivity.
• Change the network manager from Wicked to NetworkManager in openSUSE so that some networking work is done later, on the desktop..
• Disable services that don't make sense on that machine, such as btrfsmaintenance if Btrfs isn't being used, ModemManager if there's no modem, or Postfix if mail isn't being sent from it. root.
• In some specific cases, adjust the disk I/O scheduler (mq-deadline, noop/none for NVMe, etc.) and review SSD options..

Configuration details such as the following also have an impact:

• Use the "cat" compression option in /etc/mkinitcpio.conf (on Arch/Manjaro-type distributions) to create a lighter or faster-to-decompress initramfs depending on the hardware..
• Replace the udev hook with systemd in mkinitcpio to make the initrd phase more efficient with systemd's capabilities.
• Adjust kernel parameters such as libahci.ignore_sss=1 in GRUB for certain SATA controllers, whenever recommended for your hardware.

In some modern equipment, it has even been achieved Reduce boot times from the initial 7-8 seconds to around 3 seconds by making minor adjustments: disabling services, optimizing initramfs, and refining options. storageHowever, it's never a good idea to copy another user's settings without understanding them, because what works perfectly for one person could break half of another's system.

Tips for deciding what to play and what not to play

With all the information provided by systemd-analyze and systemctl, you should be able to detect units that appear to cause delays. Before you start disabling things like there's no tomorrow, it's a good idea to look up specific information about the service, your distribution, and your particular version..

Guidelines: Some sensible guidelines are:

• Check if the distribution version is in testing or is very recentSometimes the problem is simply a bug that will be fixed in later updates.
• Assess whether the slowness is "normal" on that distro and that hardware; a certain desktop or a certain set of services may be inherently heavier.
• Identify services that are clearly dispensable in your use case: ModemManager, mail daemons, printer services when you don't have a printer, monitoring daemons that you don't use, etc.
• Check if any extra software you've installed pulls its own startup service (e.g., ClamAV, ClamTK, hddtemp, custom welcome screens) and whether it's worth having it start from the beginning..
• When you see delays associated with disk drives (messages such as "A start job is running for dev-disk-by…")Check the fstab configuration or automatic mounts, because sometimes the problem is a device that no longer exists or an incorrect path.

In many cases the solution is not to disable the service, but Correct the underlying cause (for example, an unofficial welcome screen that slows down the display manager, or a misconfigured network connection that makes the manager wait indefinitely).

Impact of network and VPN services on startup

In environments where the equipment has to connect to the Internet or a private network before being "ready" (remote office automation, servers, corporate equipment), network services and VPN They can play an important role in startup time.

Using systemd-analyze blame makes it clear whether, for example, NetworkManager-wait-online.service, VPN services such as OpenVPN, WireGuard, or OpenConnect are introducing significant delays.Some practical recommendations are:

• Avoid configurations that block startup by waiting for interactive passwordsFor example, OpenVPN certificates with passphrases without any key agent managing them.
• Ensure that VPN services rely on network-online-target but do not unnecessarily block other services that do not require immediate connectivity.
• In the case of WireGuard, keep the wg-quick@ units properly configured and avoid overly complex PostUp/PreDown scripts that slow down startup..
• For OpenConnect, use well-defined Type=simple units, avoiding unnecessary script strings that can increase boot time..

All of this can be easily measured by rerunning the test. Run `systemd-analyze time` and `blame` after each change, so you can see if you've actually gained anything or just moved the problem around..

Graphic applications and other aids

Graphic alternatives: If you don't feel like constantly fighting with the terminalThere are several graphical interfaces that rely on systemd and can help you manage boot and drive status without typing so many commands.

• Systemadm (systemd System Manager)It is installed with the systemd-ui package on many distributions and appears in the menu as a system administration tool. It allows you to view drives, their status, and enable or disable them.
• systemd-kcm: Configuration module for KDE Plasma 5 (kde-config-systemd package). It integrates into "System Preferences" > "System Administration" and displays units, times, and states.
• YaST Service Administrator on openSUSE: a very powerful interface for viewing services, enabling them, disabling them, and adjusting their behavior at startup.

These tools They are useful for desktop users who simply want to check what is starting up and disable something specific without going into too much detail about .service files.For finer changes (for example, tweaking directives like After=, Wants= or TimeoutStartSec=) it is still recommended to edit or overwrite the units via /etc/systemd/system.