Analysis of Linux init system initialization, Part 1: sysvinit

Analysis of Linux init system initialization, Part 1: sysvinit

From sysvinit to systemd

In recent years, the init process of Linux has undergone two major evolution, and the traditional sysvinit has faded out of the historical stage. The new init system UpStart and systemd have their own characteristics, more and more Linux releases adopt systemd. This article briefly introduces the use and principles of these three init systems. Every Linux system administrator and system software developer should understand them to better manage systems and develop applications. This is the first part of the series. It mainly describes the features and usage of sysvinit.

What is the Init system? the history and status quo of the init system

The Linux operating system starts from the BIOS and then enters the boot loader. the bootloader loads the kernel and initializes the kernel. The last step of kernel Initialization is to start the init process with pid 1. This process is the first process in the system. It generates all other user processes.

Init exists as a daemon and is the ancestor of all other processes. The init process is unique and can complete tasks that cannot be completed by other processes.

The Init system can define, manage, and control the behavior of the init process. It is responsible for organizing and running many independent or related initial chemical operations (hence called the init system), so as to bring the computer system into the running mode of a user reservation.

It is useless to run the kernel only. The init system must replace the system into an operational state. For example, after the shell is started, human-computer interaction is available, which allows the computer to execute some booking programs to complete practical tasks. Alternatively, you can start the X graphics system to provide a better human-machine interface and perform tasks more efficiently. The shell or X system on the Character interface is a preset running mode.

The init System of most Linux distributions is compatible with System V and is called sysvinit. This is the most familiar init system. Some release versions such as Slackware use the BSD-style Init system, which is rarely used and will not be involved in this article. Other releases such as Gentoo are customized. Ubuntu and RHEL use upstart instead of the traditional sysvinit. Fedora has used a new init system called systemd since version 15.

We can see that different releases adopt different init implementations. This series of articles focuses on three main Init systems: sysvinit, UpStart and systemd. Understand their respective design features and briefly introduce their usage.

Linux is mainly used in the era of servers and PCs. SysVinit runs very well and its concept is simple and clear. It mainly depends on Shell scripts, which determines its biggest weakness: It is too slow to start. This disadvantage is not important for servers that seldom restart. When Linux is applied to mobile terminal devices, slow startup becomes a major problem. For faster start, people began to improve sysvinit, and two major new-generation init systems, upstart and systemd, were successively introduced. Upstart has been developed for more than eight years and has replaced sysvinit in many systems. Systemd appeared late, but the development is faster, and there is a tendency to replace upstart.

The first part of this article briefly introduces sysvinit.

Sysvinit Overview

Sysvinit is a system V-style init System. As its name suggests, it originated from the system V series UNIX. It provides higher flexibility than the BSD-style init system. Is a popular UNIX init system that has been used by various Linux distributions for decades.

Running level

Sysvinit uses the term runlevel to define the "Reservation running mode ". Sysvinit checks whether the '/etc/inittab' file contains the 'initdefault' item. This indicates whether the init system has a default running mode. If there is no default running mode, you will enter the system console and manually decide the running mode to enter.

The Running Mode in sysvinit describes the running Modes of various system reservations. There are usually eight running modes, namely, the running mode 0 to 6 and S or s.

Each Linux release version has different definitions for the running mode. However, 0, 1, and 6 have been unanimously agreed by everyone:

• 0 Shutdown
• 1 single user mode
• 6. Restart

The work scope of various running modes is usually defined in the/etc/inittab file. For example, RedHat defines runlevel 3 and 5. Run Mode 3 initializes the system to shell mode on the Character interface; run mode 5 initializes the system to GUI mode. For the command line interface or GUI, the running Modes 3 and 5 are complete and formal compared with other running modes, and the computer can complete the tasks required by the user. Modes 1 and S are often used for troubleshooting and recovery after system faults.

Obviously, in these different operating modes, the processes that the system needs to initialize and run are different from those that need to be initialized. For example, run Mode 3 does not need to start the X system. You only need to specify the mode to enter, and sysvinit will be responsible for executing all the initialization work required for this mode.

Sysvinit running sequence

Sysvinit uses scripts, file naming rules, and soft links to implement different runlevels. First, sysvinit needs to read the/etc/inittab file. Analyze the content of this file and obtain the following configuration information:

• Runlevel to be accessed by the System
• Definition of captured key combinations
• Define power fail/restore scripts
• Start getty and the virtual console

After obtaining the configuration information, sysvinit performs the following steps in sequence to initialize the system to the reserved runlevel X.

• /Etc/rc. d/rc. sysinit
• /Etc/rc. d/rc and/etc/rc. d/rcX. d/(X indicates the running level 0-6)
• /Etc/rc. d/rc. local
• X Display Manager (if needed)

First, run rc. sysinit to execute some important system initialization tasks. In RHEL5 of RedHat (RHEL6 already uses upstart), rc. sysinit mainly performs the following work.

• Activate udev and selinux
• Set kernel parameters defined in/etc/sysctl. conf
• Set system clock
• Load keymaps
• Enable swap Partition
• Set Host Name)
• Root partition check and remount
• Activate RAID and LVM Devices
• Enable Disk Quota
• Check and mount all file systems
• Clear expired locks and PID files

After completing the above work, sysvinit starts to run the/etc/rc. d/rc Script. Based on different runlevels, the rc Script opens the rcX. d directory (X is runlevel) for runlevel, and finds and runs all the startup scripts stored in this directory. Each runlevel X has a directory named/etc/rc. d/rcX. d.

Many different scripts are stored in these directories. Scripts whose names start with "S" are the scripts that should be run at startup. The numbers following "S" define the execution sequence of these scripts. The scripts in the/etc/rc. d/rcX. d directory are actually some soft link files, and the actual script files are stored in the/etc/init. d directory. As follows:

Listing 1. scripts in the rc5.d directory

[Root @ www ~] # Ll/etc/rc5.d/lrwxrwxrwx 1 root 16 Sep 4 2008 K02dhcdbd-> .. /init. d/dhcdbd .... (omitted in the middle ).... lrwxrwxrwx 1 root 14 Sep 4 2008 K91capi-> .. /init. d/capilrwxrwxrwx 1 root 23 Sep 4 2008 S00microcode_ctl-> .. /init. d/microcode_ctllrwxrwxrwx 1 root 22 Sep 4 2008 S02lvm2-monitor-> .. /init. d/lvm2-monitor .... (omitted in the middle ).... lrwxrwxrwx 1 root 17 Sep 4 2008 S10network-> .. /init. d/network .... (omitted in the middle ).... lrwxrwxrwx 1 root 11 Sep 4 2008 S99local-> .. /rc. locallrwxrwxrwx 1 root 16 Sep 4 2008 S99smartd-> .. /init. d/smartd .... (omitted below )....

After all the initialization scripts are executed. Run the/etc/rc. d/rc. local script in Sysvinit.

Rc. local is a place for users to customize Linux settings. You can put the things you want to set and start on your own here. There are generally more than one Linux Server user, so you have to consider this.

Sysvinit and system shutdown

Sysvinit not only initializes the system, but also closes the system. When the system is shut down, in order to ensure data consistency, you need to end and clean up in order with caution.

For example, you should stop the service that has read and write operations on the file system, and then umount the file system. Otherwise, data will be lost.

This sort of control also relies on/etc/rc. d/rcX. d/The naming rules of all scripts in the directory are controlled. All scripts starting with K in the directory will be called when the system is disabled, the numbers after the letter K define their execution sequence.

These scripts are responsible for securely stopping services or other close operations.

Sysvinit management and control functions

In addition, after the system is started, the administrator needs to manage and control the started processes. The original sysvinit package contains a series of tools to control startup, run, and close all other programs.

Halt

Stop the system.

Init

This is the init process entity of sysvinit, which runs as pid1 and is the parent process of all user processes. The main role is to use the/etc/inittab file to create a process during startup.

Killall5

Is the killall command of SystemV. Sends signals to other processes except their own session processes. Therefore, the current shell cannot be killed.

Last

Trace back to the/var/log/wtmp file (or the file specified by the-f option) to display the logon status of all users since the file was created.

Lastb

The function is similar to last. By default, the/var/log/btmp file is used to display all failed logon attempts.

Mesg

Controls the access of other users to user terminals.

Pidof

Find the process identification number (pid) of the program and output it to the standard output device.

Poweroff

It is equal to shutdown-h-p, or telinit 0. Shut down the system and cut off the power supply.

Reboot

It is equal to shutdown-r or telinit 6. Restart the system.

Runlevel

Read the system logon record file (usually/var/run/utmp) to output the previous and current system running level to the standard output device.

Shutdown

Terminate the system in a safe way. All users logging on will receive a notification that the system is about to terminate and are not allowed to log on again.

Sulogin

It is called by init when the system enters the single-user mode. When you receive the-B Option passed by the START loader, init ALSO CALLS sulogin.

Telinit

It is actually a connection of init, which is used to transmit single-character parameters and signals to init.

Utmpdump

Display the/var/run/utmp file content to the standard output device in a user-friendly format.

Wall

Send messages to all logged-on users with information permissions.

Different Linux distributions have developed some auxiliary tools based on these basic sysvinit tools to simplify the management of the init system. For example, the RHEL of RedHat developed the initscripts software package based on sysvinit, which contains a large number of startup scripts (such as rc. also provides command line tools such as service and chkconfig, and even a set of graphical interfaces to manage the init system. Other Linux distributions also have their own initscript or other init software packages to simplify sysvinit management.

As long as you understand the sysvinit mechanism, in the simplest system with only sysvinit, you can also directly call the script to start and stop the service, manually create inittab and create a soft connection to complete these tasks. Therefore, it is most important to understand the basic principles and commands of sysvinit. You can even develop your own management tools.

Summary of Sysvinit

The advantage of Sysvinit is its simple concept. Service developers only need to write the start and stop scripts, which are very clear in concept. When adding/deleting a service to a runlevel, they only need to perform some basic operations to create/delete soft connection files; this requires no additional knowledge or special definition syntax (both UpStart and Systemd require the user to learn the new language that defines the initialization behavior of the system ).

Second, another important advantage of sysvinit is to determine the execution sequence: the script is executed in strict order according to the starting number, and the script is executed after one execution is completed, which is very beneficial for error troubleshooting. UpStart and systemd support concurrent startup, which makes it difficult for no one to know the specific startup sequence.

However, serial execution of scripts leads to slow sysvinit operation efficiency. In the new IT environment, the speed of startup becomes an important issue. In addition, new Linux features such as dynamic device loading also expose some problems in sysvinit design. To address these problems, people began to find ways to improve sysvinit to speed up the startup time and solve sysvinit's own design problems.

Upstart is the first new generation init system widely used. We will introduce UpStart in the second part.

Related Articles:

1. Analysis of Linux init system initialization, Part 1: sysvinit
2. Analysis of Linux init system initialization, Part 1: UpStart
3. Analysis of Linux init system initialization, Part 1: Systemd

This article permanently updates the link address: