Brief analysis of Linux initialization init system, part 1th: sysvinit

From Sysvinit to Systemd

In recent years, the INIT process of Linux system has undergone two major evolution, the traditional sysvinit has faded out of the historical stage, the new init system upstart and systemd each have the characteristic, but the more and more Linux distribution adopts the SYSTEMD. This article briefly describes the use and rationale of these three init systems, which each Linux system administrator and system software developer should know to better manage systems and develop applications. This article is the first part of the series, mainly on the characteristics and use of sysvinit.

What is the init system, the history and status of the init system

The Linux operating system starts first from the BIOS, then into boot loader, which is loaded into the kernel by bootloader for kernel initialization. The last step in kernel initialization is to start the init process with PID 1. This process is the first process of a system. It is responsible for generating all other user processes.

Init exists as a daemon, and is the ancestor of all other processes. The init process is unique and can accomplish tasks that other processes cannot accomplish.

The init system is able to define, manage, and control the behavior of the INIT process. It is responsible for organizing and running many independent or related initiation tasks (hence known as the init system), thus allowing the computer system to enter a mode of operation for a user's subscription.

Simply running the kernel is useless, and the system must be put into an operational state by the INIT system. For example, when the shell shell is started, there is human-computer interaction, so that the machine can perform some of the booking process to accomplish meaningful tasks. Or start the X graphics system to provide a better man-machine interface and perform tasks more efficiently. Here, the shell or X system of the character interface is a preset mode of operation.

Most Linux distributions have init systems that are compatible with system V and are known as sysvinit. This is one of the most familiar init systems. Some distributions, such as Slackware, use the BSD style Init system, which is less used and is not covered in this article. Other distributions, such as Gentoo, are custom-made. Ubuntu and RHEL use upstart instead of the traditional sysvinit. Fedora, however, started with version 15 with a new init system called SYSTEMD.

You can see that different distributions have different INIT implementations, and this series of articles is intended to tell you about three major init systems: Sysvinit,upstart and SYSTEMD. Learn about their design features, and briefly describe their use.

In the era when Linux is mainly used in servers and PCs, Sysvinit runs very well and the concept is simple and clear. It relies primarily on Shell scripting, which determines its biggest weakness: startup is too slow. On servers that are rarely restarted, this disadvantage is not important. When Linux is applied to mobile devices, the slow start becomes a big problem. In order to start faster, people began to improve the sysvinit, successively appeared the upstart and Systemd these two main new generation init system. Upstart has been developed for more than 8 years and has replaced sysvinit in many systems. Systemd appeared late, but developed faster and had a tendency to replace upstart.

In the first part of this article, we first briefly introduce Sysvinit.

Back to top of page

Sysvinit Overview

The sysvinit is the System V-style init, which, as its name implies, originates from the System V series UNIX. It offers more flexibility than the BSD style init system. The UNIX init system, which has been popular for decades, has been used by various Linux distributions.

Run level

Sysvinit uses the term runlevel to define "the operating mode of the subscription". Sysvinit check if the '/etc/inittab ' file contains ' Initdefault ' entries. This tells the INIT system whether it has a default run mode. If there is no default operating mode, then the user enters the system console and manually decides which mode of operation to enter.

The operating mode in sysvinit describes the operating modes of various bookings of the system. There are typically 8 modes of operation, that is, running modes 0 to 6 and s or S.

Each Linux distribution has a different definition of the run mode. But 0,1,6 has been unanimously endorsed by everyone:

• 0 Turn off the machine
• 1 Single-User mode
• 6 restart

The working range of various operating modes is usually defined in the/etc/inittab file. For example, RedHat defines RunLevel 3 and 5. Run mode 3 initializes the system to the shell mode of the character interface, and run mode 5 initializes the system to GUI mode. Whether it is a command line interface or a GUI, run mode 3 and 5 are fully formal running states relative to other operating modes, and the computer can perform the tasks the user needs. Pattern 1,s and so on are often used for troubleshooting and recovery after a system failure.

It is clear that these different modes of operation require the process of initialization and initialization of the system to be performed differently. For example, run mode 3 does not need to start the X system. The user only needs to specify which mode to enter, and Sysvinit will be responsible for performing all the initialization required for that pattern.

Sysvinit Run Order

Sysvinit cleverly uses scripts, file naming rules, and soft links to implement different runlevel. First, Sysvinit needs to read the/etc/inittab file. Analyzing the contents of this file, it obtains some of the following configuration information:

• RunLevel the system needs to enter
• Capturing the definition of a key combination
• Defining Power Fail/restore Scripts
• Start Getty and Virtual Consoles

Once the configuration information is obtained, SYSVINIT performs the following steps sequentially to initialize the system to the RunLevel X of the subscription.

• /etc/rc.d/rc.sysinit
• /ETC/RC.D/RC and/etc/rc.d/rcx.d/(X for Run level 0-6)
• /etc/rc.d/rc.local
• X Display Manager (if required)

First, run Rc.sysinit to perform some important system initialization tasks. In the RHEL5 of RedHat Company (RHEL6 has already used upstart), Rc.sysinit mainly completes the following work.

• Activating Udev and SELinux
• Setting the kernel parameters defined in/etc/sysctl.conf
• Setting the system clock
• Load Keymaps
• Enable swap partition
• Set host name (hostname)
• Root partition Check and remount
• Activating RAID and LVM devices
• Turn on disk quotas
• Check and mount all file systems
• Purge outdated locks and PID files

After completing these tasks, Sysvinit starts running the/ETC/RC.D/RC script. Depending on the RUNLEVEL,RC script, you will open the RCX.D directory (X is runlevel) that should be runlevel, and locate and run all startup scripts that reside in that directory. Each runlevel X has one such directory, and the directory name is/ETC/RC.D/RCX.D.

There are many different scripts stored in these directories. The script whose file name starts with S is the script that should run at startup, and the number followed by S defines the order in which the scripts are executed. The scripts in the/ETC/RC.D/RCX.D directory are actually some soft link files, and the real script files are stored in the/ETC/INIT.D directory. As shown below:

Scripts in the Inventory 1.rc5.d directory

[Email protected] ~]# ll/etc/rc5.d/lrwxrwxrwx 1 root root  4 Sep  k02dhcdbd. /INIT.D/DHCDBD .... (omitted in middle) .... lrwxrwxrwx 1 root root, Sep  4-  K91capi. /init.d/capilrwxrwxrwx 1 root root (Sep  4  s00microcode_ctl). /init.d/microcode_ctllrwxrwxrwx 1 root root (Sep  4  s02lvm2-monitor). /init.d/lvm2-monitor .... (omitted in middle) .... lrwxrwxrwx 1 root root 4 Sep-  s10network. /init.d/network .... (omitted in middle) .... lrwxrwxrwx 1 root root one Sep  4  s99local. /rc.locallrwxrwxrwx 1 root root 4 Sep  -S99SMARTD. /init.d/smartd .... (omitted below) ....

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

Rc.local is where Linux leaves the user to personalize. You can put the things you personally want to set up and start up here, a Linux Server users generally more than one, so this is considered.

Sysvinit and system shutdown

Sysvinit not only needs to be responsible for initializing the system, but also for shutting down the system. When the system shuts down, in order to ensure the consistency of the data, you need to carefully in order to end and clean up the work.

For example, you should stop services that read and write to the file system before umount the file system. Otherwise, the data will be lost.

This control of the order is also dependent on the naming rules of all scripts in the/etc/rc.d/rcx.d/directory, where all scripts starting with K will be called when the system is closed and numbers after the letter K define their order of execution.

These scripts are responsible for safely stopping the service or other shutdown work.

Sysvinit Management and control functions

Also, administrators need to manage and control the processes that have already been started after the system is booted. The original Sysvinit package contains a series of tools that control the start, run, and shutdown of all other programs.

Halt

Stop the system.

Init

This is the INIT process entity of Sysvinit itself, which runs as PID1, and is the parent process for all user processes. The main function is to use the/etc/inittab file to create the process during the boot process.

Killall5

is SystemV's Killall command. Does not kill the currently used shell by signaling to processes other than its own session process.

Last

The backtracking/var/log/wtmp file (or the file specified by the-F option) shows the logon status of all users since this file was established.

Lastb

The effect is similar to last, by default using the/var/log/btmp file, which displays all failed login attempts.

Mesg

Control access to user terminals by other users.

Pidof

Identify the process identification number (PID) of the program and output to the standard output device.

Poweroff

equals shutdown-h–p, or Telinit 0. Turn off the system and switch off the power.

Reboot

equals Shutdown–r or Telinit 6. Reboot the system.

RunLevel

Reading the system's login log file (typically/var/run/utmp) outputs the previous and current system run level to the standard output device.

Shutdown

Terminates the system in a secure manner, all users who are logged on will receive notification that the system will terminate and no new logins are allowed.

Sulogin

Called by Init when the system enters single-user mode. Init also calls Sulogin when it receives the-B option passed by the boot loader.

Telinit

is actually a connection to Init that transmits single character parameters and signals to init.

Utmpdump

Displays the contents of the/var/run/utmp file to a standard output device in a user-friendly format.

Wall

Sends a message to all logged-in users who have information rights.

Different Linux distributions have developed additional tools to simplify the management of the Init system, based on the basic tools of these sysvinit. For example, RedHat's RHEL has developed initscripts software packages based on Sysvinit, including a number of startup scripts (such as Rc.sysinit), as well as command-line tools such as Service,chkconfig, and even a graphical interface to manage init system. Other Linux distributions also have their own initscript or other name of the Init package to simplify the management of sysvinit.

As long as you understand the sysvinit mechanism, in a minimalist system with only sysvinit, you can also invoke scripts to start and stop services, create inittab manually, and create soft connections to accomplish these tasks. Therefore, it is most important to understand the basic principles and commands of sysvinit. You can even develop your own set of management tools.

A summary of Sysvinit

The advantage of Sysvinit is that the concept is simple. Service developers only need to write the start and stop scripts, the concept is very clear, when the service is added/removed to a runlevel, only need to perform some basic operations to create/delete soft connection files, these do not need to learn additional knowledge or special definition syntax (upstart and SYSTEMD all require the user to learn the new language that defines the system initialization behavior.

Second, another important advantage of sysvinit is the determination of the order of execution: the script executes strictly according to the size of the boot number, and one execution completes the next, which is very useful for troubleshooting. Upstart and SYSTEMD support concurrent start-up, resulting in no one knowing the exact boot sequence, which is not easy to debug.

But the serial execution of the script causes the sysvinit to run slowly, and in the new IT environment, the startup speed becomes an important issue. In addition, the new Linux features such as dynamic device loading also expose some problems with sysvinit design. In response to these problems, people began to find ways to improve sysvinit in order to speed up startup time and solve Sysvinit's own design problems.

Upstart is the first of a new generation of INIT systems that are widely used. We introduce upstart in the second part of the next section.

Brief analysis of Linux initialization init system, part 1th: Sysvinit (RPM)