How to diagnose your slow-booting Linux PC in seconds – without spending a dime

Follow ZDNET: Add us as a preferred source on Google.

ZDNET’s key takeaways

• If your Linux machine’s boot is slow, try this tool.
• Systemd-analyze offers several options to help.
• Any systemd-supporting Linux machine will have these.

Linux has a ton of handy tools that can help you uncover things that are right, things that are wrong, and everything in between. You can customize it to your heart’s content or leave it as-is.

At some point, you might get curious as to what’s slowing down the boot time of your Linux machine. Although that might sound like a difficult task, you’d be surprised at how easy it actually is. In fact, Linux has a built-in tool to help you do just that.

Also: How to choose the right Linux desktop distribution for you

If your Linux distribution uses the systemd init system, you already have what you need to solve the problem of slow boot times, and I’m going to show you how to use the tool.

systemd-analyze

The tool in question is a part of the systemd init system, and it’s called systemd-analyze. What this tool does is analyze and debug the initialization manager in Linux. 

If you were to simply run the command systemd-analyze, you’d see results that look something like this:

Startup finished in 6.669s (kernel) + 30.368s (userspace) = 37.037s
graphical.target reached after 27.479s in userspace

As you can see above, the total startup time for one of my machines is 37.037 seconds, with 6.669s for the kernel and 30.368 seconds for userspace apps. Then there’s the graphical.target reached (the login screen) at 27.479 seconds.

Also: 8 things you can do with Linux that you can’t do with MacOS or Windows

That’s some pretty good information, but it doesn’t really help us much. The good news is that there are some important options we can use to help us figure out what’s going on.

blame

The first option is blame, which lists all systemd unit files, showing the time each unit took to initialize during the last boot, from longest to shortest. The blame option is useful for identifying which services are causing delays in the startup.

The blame option is used like this:

systemd-analyze blame

The results will look something like this:

57.158s apt-daily.service
20.879s apt-daily-upgrade.service
17.609s snapd.service
10.647s docker.service
7.217s snapd.seeded.service
4.772s fstrim.service
4.160s dev-sda2.device
3.824s motd-news.service
3.756s cloud-init-local.service
3.369s cloud-config.service
3.173s snap.lxd.activate.service
2.932s containerd.service
2.877s cloud-final.service
2.677s systemd-udev-settle.service
2.498s cloud-init.service
2.125s networkd-dispatcher.service
2.051s man-db.service

As you can see, apt-daily.service is the systemd unit taking the most time. What is that unit? The apt-daily.service unit is responsible for daily automatically checking for software updates on Debian-based Linux distributions. 

Also: The most important reason you should be using Linux at home

Although you can stop apt-daily.service, I wouldn’t recommend it. You can go through the list generated by systemd-analyze blame and see if there are services that you can reliably and safely disable to speed up boot times.

critical-chain

The critical-chain option displays the chain of units that critically slowed down the boot process. This option helps pinpoint bottlenecks in the dependency chain. In the output, the time when a unit becomes active is printed after the @ character, and the time the unit took to start is printed after the + character. 

Output for critical-chain looks something like this:

graphical.target @27.479s
└─multi-user.target @27.478s
  └─docker.service @16.830s +10.647s
    └─containerd.service @13.891s +2.932s
      └─dbus.service @13.869s
        └─basic.target @13.796s
          └─sockets.target @13.794s
            └─snapd.socket @13.745s +44ms
              └─sysinit.target @13.659s
                └─cloud-init.service @11.149s +2.498s
                  └─systemd-networkd-wait-online.service @10.024s +1.118s
                    └─systemd-networkd.service @9.838s +180ms
                      └─network-pre.target @9.832s
                        └─cloud-init-local.service @6.073s +3.756s
                          └─systemd-remount-fs.service @1.434s +174ms
                            └─systemd-journald.socket @1.147s
                              └─system.slice @1.067s
                                └─-.slice @1.067s

As you can see, the two services that could be causing bottlenecks on this system (an Ubuntu Server machine) are docker.service and containerd.service. If I wanted to speed up boot time, I could disable those services at boot and start them manually.

plot

Finally, we have plot, which generates an .svg (Scalable Vector Graphic) file that visually represents the boot process and the associated dependencies. Once the file is generated, you can open it in a web browser or image viewer that supports SVG files.

The command for this looks like:

systemd-analyze plot > boot.svg

You will then find the .svg file in the current working directory. I would suggest opening the file in a web browser because most web browsers support the file format, and the image can be rather large.

Also: How to run a Windows app on Linux with Wine

As you can see by my sample, at about 18 seconds is when the majority of applications and services start to initialize.

The systemd-analyze tool is handy to have around. With it, you can begin to troubleshoot issues that cause your system to boot more slowly than expected.