Comparative analysis of various init Methods

1. What is INIT:
　　
Init is an indispensable program in Linux.
　　
The INIT process is a user-level process started by the kernel.
　　
After the kernel is started by itself (it has been loaded into the memory, started to run, and initialized to all the device drivers and data structures), it starts a user-level program init, complete the boot process. Therefore, init is always the first process (its process number is always 1 ).
　　
In the past, the kernel used init to find it. The correct position (for Linux) is/sbin/init. If the kernel cannot find init, it will try to run/bin/sh. If the run fails, the system will also fail to start.
　　
Ii. Operation Level
　　
So what is the runtime level?
　　
Simply put, the running level is the function level currently running in the operating system. This level ranges from 1 to 6 and has different functions.
　　
Different runtime levels are defined as follows: (refer to/etc/inittab in Red Hat Linux)
　　
#0-stop (never set initdefault to 0)
　　
#1-single-user mode
　　
#2-multiple users without NFS
　　
#3-full multi-user mode (Standard Operation Level)
　　
Feedom.net

#4-useless
　　
#5-X11 (XWindow)
　　
#6-Restart (do not set initdefault to 6)
　　
These levels are specified in the/etc/inittab file. This file is the main file found by the INIT program. The first service to run is the file stored in the/etc/rc. d directory. In most Linux releases, the startup script is located in/etc/rc. d/init. d. These scripts are connected to the/etc/rc. d/rcN. d directory by using LN commands. (Here N is the running level 0-6) 3. Running level Configuration
　　
The running-level configuration is performed in the/etc/inittab line, as shown below:
　　
12: 2: Wait:/etc/init. d/RC 2
　　
The first field is an arbitrary tag;
　　
The second field indicates that this row applies to the running level (2 in this example );
　　
The third field indicates that at the running level, init should run the command in the fourth field once, and init should wait until the command ends. Run the/etc/init. d/RC command to start and end the input so that any command required to enter runtime Level 2.
　　
In the fourth field, execute the command to set all "Miscellaneous" during the running level ". It starts a service that is no longer running, and terminates the service that should not run in the new running level. The specific commands used vary depending on the Linux version, and the running-level configuration is also different.

China Network Management Alliance www_bitscn_com

　　
When init is started, it searches for a line of code in the/etc/inittab, which specifies the default running level:
　　
ID: 2: initdefault:
　　
You can require init to enter a non-default running level at startup, which is achieved by specifying a single or emergency command line parameter for the kernel. For example, you can use LILO to specify the kernel command line parameters. In this way, you can select the single-user mode (that is, run level 1 ).
　　
When the system is running, the telinit command can change the running level. When the running level changes, init runs the corresponding command from/etc/inittab.
　　
4. Special configuration in/etc/inittab
　　
The/etc/inittab has several special features that allow init to reactivate special events. These special features are marked with special keywords in the third field. For example:
　　
1. powerwait
　　
Enable init to shut down the system when the power supply is disconnected. The premise is that the software has u p S and monitors u p S and notifies init that the power supply has been cut off.
　　
2. ctrlaltdel
　　
Enable init to restart the system when you press the c t r l + a l t + d e l key combination on the console keyboard. Note: If the system is deployed in a public place, the system administrator can configure the c t r l + a l t + d e l combination key as another action, such as ignore. 3. sysinit feedom.net
　　
The command to be run when the system starts. For example, this command will clear/tmp.
　　
The special keywords listed above are incomplete. For other keywords and their usage details, refer to your inittab manual page.
　　
5. Guided by single-user mode
　　
An important operation level is the single-user mode (Operation Level 1). In this mode, only one system administrator uses a specific machine and runs as few system services as possible, including logon. Single-user mode is necessary for a few management tasks (such as running fsck on A/usr partition), because it needs to detach the partition, but this is impossible, unless all service systems have been killed.
　　
A running system can enter the single-user mode. The specific method is to use init to request the running level 1. When the kernel is started, specify the single or emergency keyword in the kernel command line to enter Level 1. The kernel also specifies the command line for init. init knows from the keyword that it should not use the default running level (the input mode of the kernel command line is related to the mode in which you start the system ).
　　
Sometimes, it is necessary to start in single-user mode. In this way, before you mount a partition, or at least before loading a scattered/usr partition, run fsck manually (any activity on a distributed file system can make it more dispersed, so run fsck as much as possible ).
　　
If the automated fsck fails to be started, the startup script init automatically enters the single-user mode. This is done to prevent the system from using an inconsistent file system, which is not automatically repaired by f s c k. File System inconsistencies are rare, and usually lead to inconsistent hard disks or experimental kernel release, but it is best to prevent problems before they happen. Network Management Network bitscn_com
　　
Due to security considerations, in single-user mode, a properly configured system requires the user to provide the root password before starting the shell script. Otherwise, it will simply enter a proper line of code for l I L O and Log On As R o t (of course, if/etc/passwd is not coherent due to file system problems, it is not suitable for the principle here. To deal with this situation, you 'd better prepare a boot disk at any time ).
　　
Different running levels have different functions and should be set according to different situations.
　　
For example, if the root password is lost, the machine can be started to enter the single-user status. Enter:
　　
Init =/bin/sh RW enables the machine to enter runtime level 1, and the root file system is mounted as read/write. He will skip all system authentication, so that you can use the passwd program to change the root password, and then start to a new running level.

Upstart is one of the most outstanding tasks of ubuntu, which can greatly speed up the process of Linux Startup. Although it is not the only next-generation INIT program, it has been used as the default INIT process of ubuntu for a long time, which will greatly help program maturity; and, upstart uses an event-based model instead of simply parallelizing various daemon. This architectural breakthrough is revolutionary. Let's take a look at this article.

Because the traditional system V init daemon (sysvinit) cannot handle modern hardware well, such as hot swapping devices, USB hard drives or mountain villages, and network file systems, UBUNTU uses upstart init daemon.

This article is based on the recently published a practical guide to Ubuntu Linux.

There are already a variety of alternative products for sysvinit. The most famous one is initng, which can be used for Debian and can also work on Ubuntu. In the same location, Solaris uses SMF (Service Management Facility), while Mac OS uses launchd. Ubuntu is more inclined to combine the advantages of these software.

Sysvinit daemon is a runtime-LEVEL initialization program that uses the runtime level (such as single-user, multi-user, etc.) and ?. D directory to the/etc/init. d directory to start and end the system service. Since feisty, Ubuntu has switched to upstart init daemon and started to convert sysvinit settings to upstart settings. This article discusses the traces of upstart and some remaining sysvinit:/etc/rc ?. D and/etc/init. d directory and concept of running level.

Upstart init daemon is based on events. When conditions change in the system, it runs a specific program. Most of the programs run here are scripts used to start or stop the service. This configuration method is similar to the concept of running the init script when the system enters a certain running level, but upstart is more flexible. Upstart can not only start or stop the service when the operation level changes, but also start or terminate the service when other system changes are received. Changes to these systems are called "events ". For example, when upstart receives the file system loading, printer installation, or other similar device addition or deletion information from udev and takes corresponding actions. Upstart can also start or close services when the system starts, closes, or the status of a task changes.

Upstart is composed of five packages (in Ubuntu) which will be installed by default:

Upstart provides upstart init daemon and initctl tools.
Upstart-logd provides the job definition files for logd daemon and logd services.
Upstart-compat-sysv provides the RC job definition file and reboot, runlevel, shutdown, telinit, and other tools for compatibility with sysvinit.
Startup-tasks provides a job definition file for system startup tasks.
System-Services provides the working definition file of the TTY service.

Definition
There are several terms that help us understand init-related things. Event is the status change information that init can obtain. Almost all internal or external State Changes of the system can trigger an event. For example, the boot program will trigger the startup event. When the system enters runtime Level 2, it will trigger the runlevel 2 event, file System loading triggers the path-mounted event, and unplug or install a hot swapping or USB device (such as a printer) also triggers a time. You can also use the initctl emit command to manually trigger an event.

A job is a series of commands that init can understand. Typical Commands include the name of a program (binary file or script) and an event. Upstart init daemon runs the corresponding program when the event is triggered. You can use the initctl Start and Stop commands to manually start or terminate a job. Jobs can be divided into tasks and services.

A task is a task that runs and returns to the waiting state after execution.

Services are jobs that do not end on their own. For example, logd daemon and Gettys are implemented as services. Init daemon monitors the status of each service. If a service encounters a problem, the service will be restarted and the service will be killed when some events are triggered or manually stopped.
The/etc/event. d directory contains a series of work definition files (Files defining the work run by upstart init Daemon ). Initially, this directory is generated by the upstart package. In ubuntu after feisty, the installed Service will add a file for controlling the service to this directory. Which of the files will be installed in/etc/rc instead ?. D and/etc/init. d directory files.

The core of upstart init daemon is a state machine. It keeps track of the status of each job. When an event is triggered, it tracks the status changes of the job. When init traces the status of a job from one to another, it may execute the job command or terminate the job.

System V's init daemon starts or stops services by changing the running level. The Ubuntu system that uses upstart init daemon does not have a running level concept. To smoothly port a running-level system to an event-based system and provide compatibility for software of other releases, UBUNTU uses upstart to simulate the running level.

In/etc/event. d/RC? What is the RC defined in the file? The job will run the/etc/init. d/RC Script, which will run the link to/etc/rc ?. Run the startup script in/etc/init. d In the d directory to simulate sysvinit. When the system enters a running level, RC? The scripts will be run at work. At the same time, upstart provides runlevel and telinit tools to provide compatibility with sysvinit.

With initctl (init control), administrators with root permissions can communicate with upstart init daemon. This tool can be used to start, stop, or report a job. For example, the initctl LIST command lists all jobs and their statuses:

$ Sudo initctl list
Logd (STOP) waiting
RC-default (STOP) waiting
RC0 (STOP) waiting
...
Tty5 (start) running, process 4720
For details about tty6 (start) Running and process 4727, refer to the man page of initctl or the example in this section. You can use the initctl HELP command (there is no horizontal bar before help) to list the commands of initctl. In addition, you can also use initctl list-help to list the help information of the LIST Command. Of course, transfer the list to other initctl commands to get the corresponding information of the command. The start, stop, and status tools are links to initctl, and the corresponding commands of initctl are directly run.

Job)
Each file in the/etc/event. d directory defines a job, which should contain at least one event and one command. When an event is triggered, init executes the corresponding command. This section describes the work defined by the Administrator and the work included in the upstart package.

The following administrator-defined jobs run a shell command using the exec keyword. In fact, you can also use this keyword to execute a shell script or a binary executable file.

$ CAT/etc/event. d/mudat
Start on runlevel 2
Exec echo "Entering multiuser mode on" $ (date)>/tmp/mudat. the out file defines a task: Execute the echo command when the system enters multi-user mode (runtime Level 2. This command writes a message containing the date and time to the/tmp/mudat. Out file. Shell will run the date command to replace the content. After the task is completed, the mudat task stops and enters the waiting state.
In the next example, the cat command shows the content of the/tmp/mudat. Out file and the initctl LIST Command about the task output (the status tool can also get the same information ):

$ CAT/tmp/mudat. Out
Entering multiuser mode on TUE Jul 10 17:34:39 PDT 2007

$ Sudo initctl list mudat
Mudat (STOP) waiting if the exec command line contains special shell characters, init will run/bin/sh (the symbolic link of dash) and hand it over for processing. Otherwise, exec runs the command line directly. If you want to execute multiple shell commands, you can put them in the script file and run the script, or use the script .... End Script (as described below ).
Upstart initdaemon can only monitor jobs that run with exec (services) and cannot monitor scripts... End Script running. In other words, the Service should run with exec, and the task can use any method.

Myjob example
You can also define an event and trigger a job. The myjob job definition file below defines a job triggered by the hithere event:

$ CAT/etc/event. d/myjob
Start on hithere
Script
Echo "Hi there, here I am !" >/Tmp/myjob. Out
Date>/tmp/myjob. Out
The end scriptmyjob file provides another method for running commands: the script and End Script keywords contain two lines of commands. These two keywords often cause init to run/bin/sh. In this example, a message and date are output to the/tmp/myjob. Out file. Now you can use the initctl emit command to trigger this job. As shown in the following figure, init shows the statuses of myjobs under our trigger:

$ Sudo initctl emit hithere
Hithere
Myjob (start) waiting
Myjob (start) starting
Myjob (start) pre-start
Myjob (start) spawned, process 6064
Myjob (start) post-START, (main) process 6064
Myjob (start) running, process 6064
Myjob (STOP) Running
Myjob (STOP) stopping
Myjob (STOP) killed
Myjob (STOP) Post-stop
Myjob (STOP) waiting

$ CAT/tmp/myjob. Out
Hi there, here I am!
Sat Jul 7 20:19:13 PDT 2007

$ Sudo initctl list myjob
In the above example, cat shows the output of myjob and initctl shows the working status. You can also use initctl start myjob (or directly use start myjob) to run it. Initctl start ten very useful commands, so that you can start a job without events. For example, you can use initctl start mudat to directly run the mudat job in the previous example without triggering the runlevel 2 event.

Specify an event with Parameters
The telinit and shutdown tools send runlevel events with parameters. For example, if shutdown sends runlevel 0, telinit 2 sends the runlevel 2 event. You can use the following format to match these events in the work definition:
Start | stop on event [Arg]

Event is an event, while Arg is an optional parameter. To stop a job when the system enters runlevel 2, you can specify stop on runlevle 2 or runlevel [235] to match runlevel 2, 3, and 5, or use runlevel [! 2.
Although upstart ignores unnecessary event parameters, parameters in the event name in the work definition file must exist in the event. For example, a runlevel event without a parameter can match all runlevel events. No matter whether a parameter exists or not, the runlevel s arg2 event does not match any event, because the runlevel event contains only one parameter.

Work definition file in/etc/event. d
As Ubuntu migrates data from sysvinit to upstart, more work will be defined in the/etc/event. d file. This section describes the working definition files in which some upstart packages are stored.

The/etc/event. d/RC2 work definition file defines the RC2 task? There is no difference between tasks. RC2 tasks are triggered when the system enters multi-user mode (the event name is runlevel 2); when the system enters any other running level (runlevel [! 2]) will end. The first part of the script calls the runlevel tool, which will show the system that it is running level 2 (of course, there is actually no such thing as running level) and assign values to two variables. The subsequent work is completed by the EXEC command. It uses parameter 2 to run the/etc/init. d/RC Script. This script uses the corresponding parameter to call/etc/rc ?. D directory. Here, the RC2 task runs the init script corresponding to the symbolic link under/etc/rc2.d.

$ CAT/etc/event. d/RC2
# RC2-runlevel 2 compatibility
#
# This task runs the old sysv-RC runlevel 2 ("multi-user") scripts. it
# Is usually started by the telinit compatibility wrapper.

Start on runlevel 2

Stop on runlevel [! 2]

Console output
Script
Set $ (runlevel-set 2 | true)
If ["$1 ″! = "Unknown"]; then
Prevlevel = $1
Runlevel = $2
Export prevlevel runlevel
Fi

Exec/etc/init. d/RC 2

End scripttty Service
The following is a job definition file for starting and monitoring the Getty process on tty1:

$ CAT/etc/event. d/tty1
# Tty1-Getty
#
# This Service maintains a Getty on tty1 from the point when
# The system is started until it is shut down again.

Start on runlevel 2
Start on runlevel 3
Start on runlevel 4
Start on runlevel 5

Stop on runlevel 0
Stop on runlevel 1
Stop on runlevel 6

Respawn
Exec/sbin/Getty 38400 tty1 is triggered by runlevel 2 to 5 (multi-user mode). It starts the Getty process and closes, restarts, or enters the single-user mode, that is, the service is disabled when running level 1, 1, and 6. The respawn keyword tells init to restart the service after the service is terminated, while the exec command enables the Getty process to run at tty1. As shown in the following figure, the initctl tool shows that the service is in the starting status, process ID 4747, And ps command shows the process of the Service:

$ Sudo initctl list tty1
Tty1 (start) running, process 4747

$ PS-Ef | grep 4747
Root 4747 1 0 jul02 tty1 00:00:00/sbin/Getty 38400 tty1rc-default task and inittab
In sysvinit, the/etc/inittab file uses the initdefault item to tell init which running level to enter when the system is started, while Ubuntu does not have the inittab file, which is the default, upstart init daemon (uses the RC-default task) to guide the system into multi-user mode (the default running level is 2 ). If you want the system to start to another running level, create an inittab file. As follows, the system enters the single-user mode by default (runlevel S ):

$ CAT/etc/inittab
: ID: S: initdefault: when the system enters the single-user (repair) mode, if the system's root account is not locked, init requires a root password before the root prompt is displayed. Otherwise, the root prompt is displayed without requiring a password.

Note: Do not set the system to run at level 0 or 6, so that the system will never start normally. To directly enter the multi-user mode (runtime Level 2), if the inittab is used to delete the file, or use the preceding example to replace s in it with 2.

In the future, the migration from sysvinit to upstart involves many parts of the Linux system. To make the conversion as smooth as possible and introduce as few problems as possible, the upstart team decided to complete the migration through multiple release.

Ubuntu uses upstart init daemon from feisty. Between feisty and gutsy 2, UBUNTU will complete the migration from sysvinit to a cleaner and more flexible upstart. As more and more services are put under the control of upstart, the content in the/etc/event. d directory will replace/etc/init. d and/etc/rc ?. D directory. The running level will no longer be formally supported by Ubuntu, although they may be retained to maintain compatibility with third-party software. In the end, upstart will replace crond.