Into the Linux systemd startup process

Linux systems are somewhat complex to start with, and there is always a place to optimize. The traditional Linux system boot process is mainly handled by the famous Init process (also known as the SYSV init boot system), while the Init-based boot system is considered an issue of insufficient efficiency, SYSTEMD is another way of booting Linux system machines, claiming to compensate for the traditional Linux SysV Init-based system disadvantages. Here we will focus on the features and controversies of SYSTEMD, but to get a better understanding of it, we'll look at what the Linux boot process is like with traditional SYSV init-based systems. To remind you, SYSTEMD is still in beta, and the future Linux operating system is ready to use SYSTEMD Boot Manager to replace the current boot process (LCTT: As of this article, the mainstream Linux distribution has many uses systemd).

Understanding the Linux boot process

The first process to start is init when we turn on the power of a Linux computer. The PID assigned to the Init process is 1. It is the parent process for all other processes in the system. When a Linux computer starts, the processor looks for the BIOS in the system store, and then the BIOS detects the system resources and then finds the first boot device, usually the hard disk, then looks for the hard drive's master boot Record (MBR), loads it into memory, and gives it control. The subsequent boot process is controlled by the MBR.

The Master boot Record initializes the bootstrapper (there are two well-known boot programs on Linux, Grub and lilo,80% Linux systems are using the Grub Boot program), and grub or LILO loads the kernel modules at this time. The kernel immediately looks for the "init" program under/sbin and executes it. Starting here, Init becomes the parent process of the Linux system. The first file that Init reads is/etc/inittab, which Init will determine the runlevel of our Linux operating system. It looks for the partition table information from the file/etc/fstab and then mounts it accordingly. Init then launches all services/scripts at the default boot level specified in/ETC/INIT.D. All services are initialized here by one of the init. In this process, Init launches only one service at a time, and all service/daemon processes are executed in the background and managed by Init.

The shutdown process is almost the opposite of the process, first Init stops all services, and the final phase uninstalls the file system.

There are some deficiencies in the startup process mentioned above. The need to replace traditional init in a better way has been around for a long time. Many alternatives have also been created. Among the more famous are Upstart,epoch,muda and Systemd. The SYSTEMD has received the most attention and is considered the best solution for the present.

Understanding SYSTEMD

The main purpose of developing SYSTEMD is to reduce system boot time and computational overhead. The SYSTEMD (System Management Daemon), which was first developed under the GNU GPL license, has now been converted to the GNU LGPL Protocol, which is now the most talked-about boot and service management process. If your Linux system is configured to use the Systemd bootloader, it takes the traditional SYSV init, and the boot process is given to SYSTEMD processing. A core feature of the SYSTEMD is that it supports the SYSV init startup script at the same time.

SYSTEMD introduces the concept of parallel start, which establishes a socket for each daemon that needs to be started, which is abstract for the process that uses them, so that they can allow interaction between different daemons. SYSTEMD creates a new process and assigns a control group (Cgroup) to each process. Processes that are in different control groups can communicate with each other through the kernel. The way the boot process is handled by SYSTEMD is pretty, and it's much better than the traditional init-based system. Let's look at some of the core features of SYSTEMD.

• The bootstrap process simplifies a lot compared to init.
• SYSTEMD supports concurrent boot process for faster boot
• Track processes through control groups, not PID
• Optimizes the way you handle the dependencies between the boot process and the service
• Support for system snapshots and restores
• Monitor services that have been started, and also support restarting crashed services
• Contains the Systemd-login module for controlling user login
• Support for loading and unloading components
• Low memory usage traces and task scheduling capabilities
• Journald module for logging events and SYSLOGD module for recording system logs

Systemd also clearly handles the system shutdown process. It has three scripts in the/usr/lib/systemd/directory, called Systemd-halt.service,systemd-poweroff.service,systemd-reboot.service, respectively. These scripts are executed when the user chooses to shut down, restart, or standby. When a shutdown event is received, SYSTEMD first uninstalls all file systems and stops all memory-swapping devices, disconnects the storage device, and then stops all remaining processes.

SYSTEMD Structure Overview

Let's look at the structural details of the boot-up process of the Linux system when using SYSTEMD as the boot program. For the sake of simplicity, we will follow the steps listed below for this process:

1. The first thing the computer does when you turn on the power is BIOS initialization. The BIOS reads the boot device settings, locates and transmits system control to the MBR (assuming the hard disk is the first boot device).

2. the MBR reads the relevant information from the grub or Lilo bootstrapper and initializes the kernel. The next step is to continue booting the system from grub or Lilo. If you specify SYSTEMD as the boot manager in the Grub configuration file, then the boot process will be completed by SYSTEMD. SYSTEMD uses "target" to handle the boot and service management processes. The "target" files in these systemd are used to group different boot units and start the synchronization process.

3. The first objective of the SYSTEMD implementation is Default.target. But actually default.target is a soft link to graphical.target . Soft links in Linux are used in the same way as shortcuts under Windows. The actual location of the file Graphical.target is/usr/lib/systemd/system/graphical.target. The contents of the Graphical.target file are shown below.

4. at this stage, Multi-user.target is started and this target places its own sub-unit in the directory "/etc/systemd/system/multi-user.target.wants In This target sets the system environment for multi-user support. Non-root users are enabled during this stage of the boot process. Firewall-related services will also start at this stage.

"Multi-user.target" will give control to another layer of "basic.target".

5. the "Basic.target" unit is used to start the General Service, especially the graphics Management Service. It uses the/etc/systemd/system/basic.target.wants directory to determine which services are to be started, and then gives control to Sysinit.targetafter Basic.target.

6. "Sysinit.target" will launch important system services such as system mounts, memory swap space and devices, kernel supplemental options, and so on. The sysinit.target is passed to local-fs.targetduring the boot process. The contents of this target unit are shown in the following surface.

7. Local-fs.target, this target unit does not initiate user-related services, it only handles the underlying core services. This target will perform the operation according to/etc/fstab and/etc/inittab.

System Boot Performance analysis

SYSTEMD provides tools for identifying and locating boot-related issues or performance impacts. Systemd-analyze is a built-in command that can be used to detect the boot process. You can identify the unit that was faulted during startup, and then track and correct the problem with the boot component. Some common systemd-analyze commands are listed below.

systemd-analyze time is used to show how long the kernel and normal user space are starting to take.

$ systemd-Time3444ms (userspace) 

systemd-analyze blame will list all running units, sorted by the time it takes to start from initialization to current, and in this way you will know which services take a long time to boot during the boot process.

$ systemd-analyze Blame2001ms mysqld.service234ms httpd.service191ms vmms.service  

Systemd-analyze Verify shows whether there is a syntax error in all system units.

systemd-analyze plot can be used to write the entire boot process into an SVG format file. The entire boot process is very long and inconvenient to read, so with this command we can write the output to a file and then view and analyze it. The following command is to do this.

Boot. svg

Systemd's controversy

SYSTEMD is not fortunate enough to get everyone's favor, and some experts and administrators disagree about how it works and how it is developed. According to Systemd's criticism, it is not a "Unix-like" way because it tries to replace some system services. Some experts also dislike the idea of using binary configuration files. It is said that editing the Systemd configuration is very difficult and does not have a graphical tool available.

How to test systemd on Ubuntu 14.04 and 12.04

Originally, Ubuntu decided to use SYSTEMD to replace the current boot process from Ubuntu 16.04 Lts. Ubuntu 16.04 is expected to be released in April 2016, but given the popularity and needs of the SYSTEMD, the ubuntu 15.04 has just been released as the default boot program. In addition, users of Ubuntu 14.04 trusty Tahr and Ubuntu 12.04 precise pangolin can test systemd on their machines. The testing process is not complicated, all you have to do is include the relevant PPA in the system, update the warehouse and upgrade the system.

Disclaimer : Please note that it is still in the testing and development phase of Ubuntu. Upgrading a test package can lead to some unknown errors that could damage your system configuration in the worst case scenario. Make sure that you have backed up important data before you try to upgrade.

Run the following command in the terminal to add the PPA to your Ubuntu system:

sudo add-apt-repository ppa:pitti/systemd

You will see the warning message because we are trying to use the temp/test PPA, and they are not recommended for the actual working machine.

Then run the following command to update the APT package management repository.

sudo apt-get update

Run the following command to upgrade the system.

sudo apt-get Dist-upgrade

In this respect, you should already be able to see the SYSTEMD configuration file in your Ubuntu system, and open the/lib/systemd/directory to see these files.

OK, now let's edit the grub configuration file to specify SYSTEMD as the default bootstrapper. You can use the Gedit text editor to edit the grub configuration file.

sudo gedit/etc/default/grub

Modify the Grubcmdlinelinux_default entry in the file and set its parameters to: "init=/lib/systemd/systemd"

In this way, your Ubuntu system is no longer using the traditional bootloader, instead using the Systemd Manager. Restart your machine and check the SYSTEMD boot process.

Conclusion

Systemd is undoubtedly a big step forward in improving the Linux boot process, which contains a beautiful set of libraries and daemons to work with to optimize the system boot and shutdown processes. Many Linux distributions are preparing to use it as their own official boot program. In future Linux distributions, we will expect to see SYSTEMD powered on. But on the other hand, in order to be successful and widely used, systemd still needs to deal with critical opinions seriously.

Into the Linux systemd startup process