System boot speeds

While Shashank Sharma doesn’t much care for cars that can go 0-100 in six seconds or less, he does expect his distro to boot up in no time at all.

All applications and graphical environments are now easily available for just about all Linux distributions. In those instances when they’re not offered out of the box, the distribution provides easy mechanisms to install them using software repositories. This is why there’s little to differentiate between any two distributions. However, the one area where distributions still fiercely compete with one another is performance: the optimum use of available system resources to boot you to the desktop in the least amount of time possible.

Almost all major Linux distributions now use systemd as the underlying init system. Unlike its peers such as System V, systemd is a software suite comprising various daemons and other system components and utilities. These include systemctl, which can be used to start/stop or enable/ disable a service as well as systemd-analyze, which can be used to study boot-up performance statistics. If you find your distribution taking far longer to boot than what’s advertised for the same specs, looking at boot statistics might reveal the bottleneck, and help you speed up the process.

Unlike the other applications and utilities we’ve featured in the past, you don’t need to install systemd-analyze because it’s part of the systemd suit of applications. When you run the systemd-analyze command, without any other options, the tool will provide the total time taken to boot the system:

$ systemd-analyze Startup finished in 5.656s (kernel) + 1min 6.557s (userspace) = 1min 12.214s

graphical.target reached after 1min 5.129s in userspace

As you can see, the command tells us how much time it took to start the kernel, as well as boot up the userspace components. The kernel space includes the kernel and device drivers that need to start when you boot into an operating system. Everything else, be it libraries or other daemons for example, are part of the user space.

From the output of the systemdanalyze command, we can see that it only took about 5.6 seconds for the kernel to start up, but more than a minute for the user space to become active. As you can imagine, this is incredibly slow, especially for a quad core machine with 12GB of RAM installed.

The blame game

To find out what service is to blame for the boot times, you must run the systemd-analyze blame command and study its findings:

$ systemd-analyze blame 28.458s udisks2.service ≥ 27.409s dev-sda7.device ≥ 23.643s snapd.service ≥ 21.156s apt-daily.service ≥ 17.497s dev-sda6.device ≥ 16.380s networkd-dispatcher. service ≥

15.827s systemd-journal-flush. service

The actual output to the command is rather long, but we’ve had to cut it short because of space constraints. You can navigate through the output using arrow keys. The output sorts the different services based on the amount of time taken to start each of them.

Many of the different services start in parallel, which is why the total of these different numbers adds up to significantly more than the actual time reported by the systemd-analyze. This utility gives you some indication of the services that perhaps require closer scrutiny if you wish to improve boot times.

You should also bear in mind that the boot times will vary on each reboot, depending on the changes made to the system by installing or removing applications. In our example, notice how snapd.service takes 23.6 seconds. If we were to remove or stop using Snap packages, and stop or disable the Snap service, the boot times will improve. But you shouldn’t start making changes to your system on the basis of the output of the blame command alone.

Chain reaction

Some processes during startup cannot begin until some of the other process that they depend upon start successfully. You can obtain a list of all such services

that slow down the boot by making other services wait by using the critical-chain subcommand:

$ systemd-analyze criticalchain

The time when unit became active or started is printed after the “@” character.

The time the unit took to start is printed after the “+” character. graphical.target @57.345s multi-user.target @57.344s smbd.service @53.719s +3.625s

nmbd.service @43.264s +10.452s

network-online.target @43.090s

NetworkManager-waitonline.service @33.967s +9.122s

NetworkManager. service @27.506s +6.459s

dbus.service

dev-disk-by\ x2duuid-982f7286\x2d84f5\ x2d48e5\x2d807e\≥

dev-disk-by\ x2duuid-982f7286\x2d84f5\ x2d48e5\x2d807≥

Here, the numbers following the @ symbol show the absolute number of seconds since startup began when the unit becomes active. Similarly, the numbers following the + symbol show the amount of time it takes for the given unit to start.

You can also check the criticalchain of any service by using the systemd-analyze critical-chain command:

systemd-analyze critical-chain NetworkManager.service

The time when unit became active or started is printed after the “@” character.

The time the unit took to start is printed after the “+” character.

NetworkManager.service +6.459s dbus.service @27.502s basic.target @27.366s sockets.target @27.366s snapd.socket @27.361s +1ms

sysinit.target @27.189s swap.target @27.189s dev-disk-by\x2duuid

The systemdanalyze security command can be used to examine the security and sandboxing settings of the different services.