Linux Boot-Time

Jarret B

Active Member
Staff member
Credits
858
When starting a Linux system you may see there are delays when certain updates are performed or new applications installed. To help speed up the Linux boot time you will need to determine where the time is being delayed the most.

There are four basic places where the delay can occur. These different areas are:
  1. Firmware
  2. Loader
  3. Kernel
  4. Userspace
Let’s look at these first to see what occurs during these stages.

Firmware

The firmware is the 'software' which is loaded by the hardware. For example, when your video card is powered on it has built-in code which makes it accessible to the Linux Operating System (OS). In this manner, the OS can control the aspects of the video card. Another example is motherboard firmware which can allow the OS to control the processor fan.

Every PC, Laptop, Server, etc. has firmware. The firmware can be updated in most cases by system updates. Most system updates are not automatic and must be downloaded from the system manufacturer. For example, if you have an AMD Radeon video card then you can go to the AMD website and possibly find an update for your video card.

NOTE: Even printers and other external devices can have firmware. These devices should not have any effect on the boot time. Only the internal devices or those involved in the system startup should matter. If you use an external hard drive for the OS to boot from then the firmware on the disk drive will matter.

Loader

After the firmware is loaded then the Boot Loader takes over the booting process. The Boot Loader will load the Linux kernel and the Linux RAM Disk (initrd).

One popular Boot Loader is the GRand Unified Bootloader (GRUB). There is usually a delay in the bootloader. It allows a user to select an option from a menu before a default option is selected when the timeout occurs.

Kernel

The Linux Kernel is software that interacts with the hardware through the software. Any applications on a system send commands to the kernel. The kernel will use the commands to communicate with the hardware. It also allows hardware to interact with the software.

One example is when a key is pressed on the keyboard. The hardware sends the information to the kernel which transmits a signal to the software noting a key was pressed. The same is true for a mouse click. When an icon is selected on the desktop a signal is sent to the kernel which interacts with the software to determine what occurs. The information is then sent to the kernel. The kernel sends signals to the hard drive to read a program.
The program is read into memory and executed. So, if you double-click on a web browser icon the program is loaded into memory and started.

Many things are controlled in the background by the kernel such as services, system updates, hardware control, etc.

User Space

Any other software not included in the firmware, boot loader and kernel is the userspace. These programs include all of the applications, drivers and other files on the system which can be executed.

The User Space is sometimes referred to as the 'userland'. In most cases, this section of the boot process will be the largest part of the Boot Time.

Determine Boot-Time

The quickest way to determine the Boot Time of these four sections is by issuing the following command in a Terminal:

systemd-analyze

Output similar to Figure 1 should be shown.

Figure 01.jpg

FIGURE 1

The Firmware took 8.76 seconds, the Loader took 5.974 seconds, the Kernel took 6.148 seconds and the User Space took 1 minute 33.466 seconds. The majority of the load time was in the User Space.

If you have a Firmware load time that is abnormally long then you can change things in your BIOS. Disabling unneeded features can help the Firmware boot time.

Issues with the Loader may require a reset of the options in the Boot Loader program. Check for any options which not needed.

Kernel load times are not an issue unless you have compiled the kernel for extra features. You may need to see what you have added that is not needed. You could also try a stock kernel and see if it loads faster.

You may also notice that the Graphical User Interface (GUI) was started in 1 minute and 10.144 seconds into the User Space loading.

The Userspace is usually the biggest part of the Boot-Time. The individual times on the User Space can be determined from a Terminal with the command:

systemd-analyze blame

The output is a list of all the items loading in User Space sorted from the longest load time first and the shortest last. An example is shown in Figure 2.

Figure 02.jpg

FIGURE 2

Looking at Figure 02 you can disregard the first line. The first line is a system update being performed in the background before the login took place. You can look down the list and see everything that loaded on the system. If you perform this listing and see something that you do not need then you can unload the program or disable the service.

After anything is changed you can reboot the system and check the command again to see how the boot time has changed. The process is a great way to optimize the boot time as well as lowering your memory usage if apps are removed and services disabled.

Removing an Application

There is a way to find an application more easily than on the listing from the systemd-analyze command. Let’s say on my output in Figure 02 there was a line from a program called XY1 which took over a minute to load. If I no longer needed the app then I may want to remove the program. In a Terminal I could type ‘sudo apt purge XY1’, but nothing happened because the program was not found.

To find the app I can run the command ‘dpkg -l | grep -i XY1’. The listing of programs found should include the program name. I can use the name to purge it by replacing the name in the ‘sudo apt purge’ command. Once the command completes, then you can run ‘sudo apt autoremove’ to finish uninstalling anything left that is not needed.

Stopping a Service

Some of the items listed in the output are services. These are denoted by the ending ‘.service’.

Just because a service is listed here does not mean that it remains active after boot. For instance, let’s look at the ‘snap.service’. I can run the command ‘systemctl show snap.service | grep ActiveState’. When I execute the command I get a response of ‘inactive’. This means that the service is not active. If I ran the command for the ‘libvirtd.service’ then it does come back as ‘active’.

If a service is active then you can stop the service with the command ‘systemctl stop libvirtd.service’. The command will stop the service until you reboot the system and it is restarted.

If you want to disable the service even after a reboot then there is a different command. The command to disable a service is ‘systemctl disable name.service’.

NOTE: When performing a ‘systemctl’ command you may need to run as Root by using ‘sudo’ at the beginning of the command.

Optimized System Boot-Time

I found a very good optimized system and found the times as:

Startup finished in 3.863s (firmware) + 13.494s (loader) + 1.637s (kernel) + 4.222s (userspace) = 23.218s
graphical.target reached after 4.217s in userspace


The ‘systemd-analyze blame’ command returned the following:

2.386s sendmail.service
946ms mysql.service
724ms systemd-random-seed.service
518ms logrotate.service
499ms systemd-resolved.service
351ms systemd-logind.service
313ms dev-nvme0n1p3.device
306ms systemd-journald.service
275ms apache2.service
271ms upower.service
217ms udisks2.service
205ms systemd-timesyncd.service
205ms accounts-daemon.service
152ms gpm.service
151ms edac.service
144ms lm-sensors.service
139ms loadcpufreq.service
135ms apparmor.service
130ms systemd-modules-load.service
117ms avahi-daemon.service
115ms bluetooth.service
113ms keyboard-setup.service
109ms systemd-udev-trigger.service
108ms ufw.service
99ms tmp.mount
95ms NetworkManager.service
91ms grub-common.service
87ms binfmt-support.service
86ms alsa-restore.service
77ms [mailto:[email protected]\x2duuid-277d9b73\x2d1fd1\x2d42e3\x2d9275\x2d1a6febaae04f.service][email protected]\x2duuid-277d9b73\x2d1fd1\x2d42e3\x2d9275\x2d1a6febaae04f.service
77ms hddtemp.service
76ms [mailto:[email protected]\x2duuid-a9d8fee1\x2debd3\x2d45f8\x2db30b\x2de0d409fc0c9a.service][email protected]\x2duuid-a9d8fee1\x2debd3\x2d45f8\x2db30b\x2de0d409fc0c9a.service
74ms [mailto:[email protected]\x2duuid-3d237d5c\x2dc81f\x2d472e\x2dad35\x2dc12a1ae3adc5.service][email protected]\x2duuid-3d237d5c\x2dc81f\x2d472e\x2dad35\x2dc12a1ae3adc5.service
73ms [mailto:sys[email protected]\x2duuid-E87C\x2d35EF.service][email protected]\x2duuid-E87C\x2d35EF.service
72ms blueman-mechanism.service
71ms ksm.service
67ms thermald.service
67ms motion.service
66ms [email protected]
66ms systemd-udevd.service
64ms saslauthd.service
62ms wpa_supplicant.service
55ms colord.service
52ms grub-initrd-fallback.service
51ms systemd-sysctl.service
51ms dev-disk-by\x2duuid-fcdd39a3\x2d8a94\x2d441b\x2d8245\x2d3388772a6ab9.swap
46ms cpufrequtils.service
44ms polkit.service
43ms kerneloops.service
42ms netfilter-persistent.service
38ms systemd-tmpfiles-setup.service
34ms networking.service
32ms sshguard.service
29ms fwupd-refresh.service
23ms console-setup.service
23ms boot-efi.mount
23ms ssh.service
22ms systemd-rfkill.service
20ms rsyslog.service
18ms systemd-journal-flush.service
18ms systemd-user-sessions.service
18ms plymouth-read-write.service
16ms home.mount
16ms proc-sys-fs-binfmt_misc.mount
16ms boot.mount
15ms var.mount
15ms [email protected]
14ms systemd-remount-fs.service
13ms systemd-tmpfiles-setup-dev.service
13ms plymouth-quit-wait.service
13ms systemd-update-utmp.service
13ms sys-kernel-config.mount
12ms [email protected]
12ms plymouth-quit.service
11ms systemd-tmpfiles-clean.service
10ms systemd-sysusers.service
9ms xdm.service
9ms sys-fs-fuse-connections.mount
8ms dev-hugepages.mount
8ms dev-mqueue.mount
8ms blk-availability.service
7ms e2scrub_all.service
7ms kmod-static-nodes.service
6ms [mailto:[email protected]:nvidia_0.service][email protected]:nvidia_0.service
5ms [email protected]
5ms setvtrgb.service
4ms systemd-update-utmp-runlevel.service
3ms nvidia-persistenced.service
3ms ifupdown-pre.service
2ms rtkit-daemon.service
1ms mnt-huge.mount


Conclusion

The two simple commands can help you determine Boot Times for your system. From these times you can find any problems which are causing your system to boot slowly.

I hope this helps you optimize your system to improve boot performance.
 


Members online


Latest posts

Top