Systemd Boot Process a Close Look in Linux

The way Linux system boots up is quite complex and there has always been a need to optimize the way it works. The traditional boot process of the Linux system is mainly handled by the well know init process (also known as SysV init boot system).

Systemd, on the other hand is an initialization system and service manager wrote by Lennart Poettering and Kay Sievers. Many major Linux distributions have now adopted systemd as the default init system.

In this tutorial, I will go through the Linux system boot process with systemd.

Understanding Systemd

Systemd (System Manager Daemon), originally developed under GNU General Public License, is now under GNU Lesser General Public License. Reducing the boot time and computational overhead is the main objective of developing the Systemd.

One of the core features of Systemd is that it supports post-boot scripts of SysV Init ie backward compatible with SysV init scripts.

The way systemd handles the start up process is quite neat and much optimized as compared to the traditional init based system.

Let’s review some of the core features of Systemd.

  • The boot process is much simpler as compared to the init
  • Systemd provides concurrent and parallel process of system boot so it ensures better boot speed
  • Processes are tracked using control groups, not by PIDs
  • Improved ways to handle boot and services dependencies.
  • Capability of system snapshots and restore
  • Monitoring of started services ; also capabale of restarting any crashed services
  • Includes systemd-login module to control user logins.
  • Ability to add and remove components
  • Low memory foot prints and ability for job scheduling
  • Journald module for event logging and syslogd module for system log.

Systemd handles system shutdown process in a well organized way as well. It has three script located inside '/usr/lib/systemd/' directory, named systemd-halt.service, systemd-poweroff.service, systemd-reboot.service. These scripts are executed when a user chooses to shutdown, reboot or halt Linux system.

In the event of shutdown, the systemd first un-mount all file systems and disabled all swap devices, detaches the storage devices, and kills remaining processes.

systemd boot chart

Boot process with Systemd

Let’s check Linux system boot process when it is using systemd as boot and services manager.

For the sake of simplicity, we are listing the process in steps below:

01.  The very first steps when you power on your system is the  BIOS initialization. BIOS reads the boot device settings, locates and hands over control to MBR (assuming hard disk is set as first boot device).

02.  MBR reads information from Grub or LILO boot loader and initializes the kernel.  Once kernel loaded into initial RAM disk, it begins the systemd initialization.

Systemd handles boot and services management process using “targets”. The ”target" files in systemd are used for grouping different boot units and start up synchronization processes.

03.  The very first target executed by systemd is default.target. But default.target is actually a symlink to graphical.target.  Symlink in linux works just like shortcuts in Windows. Graphical.target file is located at /usr/lib/systemd/system/graphical.target path. We have shown the contents of graphical.target file in the following screenshot.

graphical target

04. At this stage, multi-user.target has been invoked and this target keeps its further sub-units inside  “/etc/systemd/system/multi-user.target.wants” directory. This target sets the environment for multi user support. None root users are enabled at this stage of boot up process. Firewall related services are started on this stage of boot as well.

multi-user target

"multi-user.target" passes control to another layer “basic.target”.

Basic Target
05. "basic.target" unit is the one that starts usual services specially graphical manager service. It uses /etc/systemd/system/basic.target.wants directory to decide which services need to be started, basic.target passes on control to sysinit.target.

Sysint Target

06. "Sysinit.target" starts important system services like file system mounting, swap spaces, and devices, kernel additional options etc. Sysinit.target passes on startup process to local-fs.target. The contents of this target unit are shown in the following screenshot.

local FS Target
07. local-fs.target - no user-related services are started by this target unit, it handles core low-level services only. This target is the one performing actions on the basis of '/etc/fstab' and '/etc/inittab' files.

Analyzing System Boot Performance

Systemd offers tools to identify and troubleshoot boot related issues or performance concerns. Systemd-analyze is a built-in command which lets you examine boot process. You can find out the units which are facing errors during boot up and can further trace and correct boot component issues. Some useful systemd-analyze commands are listed below.

systemd-analyze time shows the time spent in kernel,  and normal user space.

$ systemd-analyze time

Startup finished in 1440ms (kernel) + 3444ms (userspace)

systemd-analyze blame prints a list of all running units, sorted  by the time taken by then to initialize, in this way you can have idea of which services are taking long time to start during boot up.

$ systemd-analyze blame

2001ms mysqld.service
234ms httpd.service
191ms vmms.service

systemd-analyze verify shows if there are any syntax errors in the system units. Systemd-analyze plot can be used to write down whole startup process to a SVG formate file. Whole boot process is very lengthy to read, so using this command we can dump the output of whole boot processing into a file and then can read and analyze it further. The following command will take care of this.

systemd-analyze plot > boot.svg

Systemd Controversies

Systemd has not been lucky to receive love from everyone, some professionals and administrators have different opinions on its working and developments.  Per critics of Systemd, it’s “not Unix-like” because it tried to replace some system services.

Some professionals don’t like the idea of using binary configuration files as well. It is said that editing systemd configuration is not an easy tasks and there are no graphical tools available for this purpose.

Conclusion

With that said, I hope you enjoyed reading this tutorial on systemd boot process step. Please feel free to leave your suggestions in the below comment section.

Aun Raza 6:00 am

Comments

Your email address will not be published. Required fields are marked *

All comments are subject to moderation.

2 Comments

  1. Helpful article but...

    "Some professionals don’t like the idea of using binary configuration files as well." - can you names these files, i don't know which ones you are refering to.?

    "systemd-analyze verify" - is this a special, i couldn't get it to recognise "verify" and "man systemd-analyze " doesn;t note it.

    1. Hello

      Thanks for the comment :)

      /etc/binfmt.d is used for additional binary formats for systemd executables at boot. More details http://www.freedesktop.org/software/systemd/man/binfmt.d.html

      Regarding "systemd-analyze verify", we are able to see it in Fedora 21, Ubuntu 14.10 LTS:

      ==
      SYSTEMD-ANALYZE(1) systemd-analyze SYSTEMD-ANALYZE(1)

      NAME
      systemd-analyze - Analyze system boot-up performance

      SYNOPSIS
      systemd-analyze [OPTIONS...] [time]

      systemd-analyze [OPTIONS...] blame

      systemd-analyze [OPTIONS...] critical-chain [UNIT...]

      systemd-analyze [OPTIONS...] plot [> file.svg]

      systemd-analyze [OPTIONS...] dot [PATTERN...] [> file.dot]

      systemd-analyze [OPTIONS...] dump

      systemd-analyze [OPTIONS...] set-log-level [LEVEL]

      systemd-analyze [OPTIONS...] verify [FILES...]
      ==

      Which version of the os you are using? so we may test it further accordingly. Thanks for your feedback!