Linux initialization init system 1---sysvinit__linux

Reprint Address: http://www.ibm.com/developerworks/cn/linux/1407_liuming_init1/

from Sysvinit to Systemd

In recent years, the INIT process of the Linux system has undergone two major evolutions, the traditional sysvinit has faded out of the history stage, the new init system upstart and systemd each have characteristic, and more and more Linux distributions have adopted systemd. This article briefly describes the use and rationale of these three init systems, and each Linux system administrator and system software developer should be aware of them in order to better manage systems and develop applications. This article is the first part of the series, mainly about 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 the boot loader, which is loaded into the kernel by bootloader for kernel initialization. The final step in kernel initialization is to start the init process with PID 1. This process is the first process of the 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, capable of accomplishing tasks that other processes cannot.

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 initiation work (so called the init system), allowing the computer system to enter the operating mode of a user subscription.

It is no practical use to run the kernel alone, and the system must be put into operational state by the INIT system. For example, after starting the shell shell, there is human-computer interaction, so that the computer can perform some booking procedures to complete meaningful tasks. Or start the X graphics system to provide a better man-machine interface, more efficient completion of the task. Here, the character interface of the shell or X system is a preset mode of operation.

The init system for most Linux distributions is compatible with system V, 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 no longer covered in this article. Other distributions, such as Gentoo, are customized. Ubuntu and RHEL use upstart instead of traditional sysvinit. Fedora started with a new init system called Systemd from version 15.

You can see that different distributions are implemented with different INIT implementations, and this series is intended to describe three major init systems: Sysvinit,upstart and SYSTEMD. Understand their respective design features and briefly describe their use.

In the times when Linux is mainly used in servers and PCs, Sysvinit runs very well and the concept is simple and clear. It relies heavily on Shell scripting, which determines its greatest weakness: booting too slowly. This shortcoming is not important on a Server that is rarely restarted. And when Linux is applied to mobile terminals, startup slow becomes a big problem. In order to start faster, people began to improve the sysvinit, and the upstart and systemd of the two major new generation INIT systems emerged successively. Upstart has been developed for more than 8 years and has replaced Sysvinit in a number of systems. Systemd appeared later, but developed faster, which greatly replaced the upstart trend.

The first part of this article first briefly introduces Sysvinit.

Back to the top sysvinit Overview

Sysvinit is System V-style init, which, as its name suggests, originates from System V-series UNIX. It offers a higher flexibility than the BSD-style init system. The UNIX init system, which has been in vogue for decades, has been adopted by various Linux distributions. Run Level

Sysvinit uses the term runlevel to define the "subscription run mode". Sysvinit Check to see if the '/etc/inittab ' file contains ' Initdefault ' items. This tells the INIT system if it has a default mode of operation. If there is no default mode of operation, the user will enter the system console and manually decide what mode of operation to enter.

The operating mode in sysvinit describes the operating mode of various bookings for the system. There are usually 8 modes of operation, that is, run mode 0 through 6 and s or S.

Each Linux distribution has a different definition of the run mode. But 0,1,6 got everyone's unanimous approval: 0 shutdown 1 Single user mode 6 reboot

The scope of work for various operating modes is typically defined in the/etc/inittab file. For example, RedHat defines RunLevel 3 and 5. Run mode 3 initializes the system to the character interface Shell mode, and run mode 5 initializes the system to GUI mode. Whether it's a command-line interface or a GUI, run mode 3 and 5 are complete, formal running conditions relative to the rest of the runtime, and the computer can perform the tasks that the user needs. Pattern 1,s and so on are often used for fault and recovery after system failure.

Obviously, the processes that the system needs to initialize and the initialization preparation required for these different operating modes are different. 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 necessary for that pattern. Sysvinit Run Order

Sysvinit skillfully 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 the following configuration information: The system needs to enter the definition of RunLevel capture combination key definition power Fail/restore Script start Getty and Virtual Console

After you get the configuration information, sysvinit the system to the subscribed RunLevel X by performing the following steps sequentially. /ETC/RC.D/RC.SYSINIT/ETC/RC.D/RC and/etc/rc.d/rcx.d/(x represents 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 RedHat Company's RHEL5 (RHEL6 has already used upstart), Rc.sysinit mainly completes the following work. Activate Udev and SELinux settings define kernel parameter settings in/etc/sysctl.conf system clock load keymaps enable swap partition set host name (hostname) root partition check and remount activate RAID and LVM device open Disk quotas check and mount all file systems purge expired locks and PID files

After you have done this, Sysvinit begins to run the/ETC/RC.D/RC script. Depending on the RUNLEVEL,RC script will open the RCX.D directory (X is runlevel) that should be runlevel, locate and run all the startup scripts that are stored in that directory. Each runlevel X has a directory named/ETC/RC.D/RCX.D.

There are a lot of different scripts stored in these directories. The script whose filename begins with S is the script that should run when it starts, and the numbers followed by S define the order in which the scripts are executed. The scripts in the/ETC/RC.D/RCX.D directory are actually soft link files, and the real script files are stored in the/ETC/INIT.D directory. As follows: scripts in the list 1.rc5.d directory

[Root@www ~]# ll/etc/rc5.d/
lrwxrwxrwx 1 root Sep 4 2008  k02dhcdbd  . /init.d/dhcdbd .....
(omitted in the middle) ....
lrwxrwxrwx 1 root Sep  4  2008 K91capi->. /init.d/capi
lrwxrwxrwx 1 root Sep  4  2008 S00microcode_ctl->. /init.d/microcode_ctl
lrwxrwxrwx 1 root Sep  4  2008 S02lvm2-monitor->. /init.d/lvm2-monitor .....
(omitted in the middle) ....
lrwxrwxrwx 1 root Sep  4  2008 S10network->. /init.d/network .....
(omitted in the middle) ....
lrwxrwxrwx 1 root Sep  4  2008 s99local->. /rc.local
lrwxrwxrwx 1 root Sep  4  2008 S99SMARTD->. /init.d/smartd .....
(omitted below) ....

When all the initialization scripts have finished executing. Sysvinit Run the/etc/rc.d/rc.local script.

Rc.local is where Linux leaves the user with personalization. You can put your personal want to set up and start things here, a Linux server users in general more than one, so there is such a consideration. Sysvinit and system shutdown

Sysvinit not only needs to be responsible for initializing the system, it also needs to be responsible for shutting down the system. In order to ensure data consistency when the system shuts down, you need to be careful in order to finish and clean up the work.

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

This order of control is also controlled by the naming rules of all scripts in the/etc/rc.d/rcx.d/directory, where all scripts beginning with K will be invoked when the system is shut down, 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

In addition, after the system starts, the administrator also needs to manage and control the processes that have been started. The original Sysvinit package contains a series of tools for controlling startup, running, and closing all other programs.

Halt

Stop the system.

Init

This is the sysvinit itself's init process entity, which runs as PID1 and is the parent process for all user processes. The primary role is to create a process using the/etc/inittab file during the startup process.

Killall5

Is SYSTEMV's killall order. A signal is sent to a process other than its own session process, so the shell currently in use cannot be killed.

Last

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

Lastb

function is similar to last, using the/var/log/btmp file by default to display all failed login attempts.

Mesg

Controls access to user terminals by other users.

Pidof

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

Poweroff

Equal to Shutdown-h–p, or Telinit 0. Shut down the system and cut off the power.

Reboot

Equal to Shutdown–r or Telinit 6. Reboot the system.

RunLevel

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

Shutdown

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

Sulogin

When the system enters Single-user mode, it is invoked by Init. When you receive the-B option passed by the boot loader, Init also invokes Sulogin.

Telinit

is actually a connection to INIT, which is used to transfer single character parameters and signals to init.

Utmpdump

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

Wall

Send a message to all logged-in users who have information permissions.

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

As long as you understand the sysvinit mechanism, in a minimalist system with only sysvinit, you can simply invoke the script to start and stop the service, create the inittab manually, and create a soft connection to accomplish these tasks. It is therefore most important to understand the basic principles and commands of sysvinit. You can even develop your own set of management tools. Summary of Sysvinit

The advantage of Sysvinit is that the concept is simple. Service developers only need to write startup and stop scripts, the concept is very clear; when you add/remove a service to a runlevel, you only have to perform some basic operations to create/delete soft connection files; None of this requires learning additional knowledge or special definition syntax (upstart and Systemd require users to learn new languages that define system initialization behavior.

Second, another important advantage of sysvinit is the determination of the order of execution: the script executes strictly in the order of the number of boot digits, one execution and then the next, which is very useful for error troubleshooting. Upstart and SYSTEMD support concurrent startup, which causes no one to be sure about the specific boot sequence, which is not easy to debug.

But serial execution of scripts results in slow running of Sysvinit, which is an important issue in the new IT environment. In addition, the new Linux features such as dynamic device loading also expose some problems of sysvinit design. In response to these problems, people began to think of ways to improve sysvinit in order to speed up the start-up time and solve Sysvinit's own design problems.

Upstart is the first new generation init system to be widely used. We'll introduce upstart in the next part.