Recently, because of the Linux development with teammates, because not the same version of Linux (he used the arch, I use Ubuntu), and then often the configuration is not the same, as the Inittab file, and then delve into the reason:
The Linux kernel starts init, and the init process ID is 1, which is the parent process of all processes, and all processes are controlled by it.
Ubuntu start-up is controlled by upstart , since 9.10 no longer uses the/ETC/EVENT.D directory configuration file, changed to/etc/init.
To see the current runlevel, Ubuntu desktop defaults to 2.
?
Ubuntu system Operating level:
?
12345 |
0 系统停机状态 1 单用户或系统维护状态 2 ~ 5 多用户状态 6 重新启动 S |
To switch the run level, execute the command:
?
That is, after the init command followed by a parameter, this parameter is the run level code to switch to the run level, such as: Shutdown with the init 0 command, restart with the init 6 command.
That's one of our shutdown commands. The origin of the $ sudo init 0:
?
To view the current operating level of the system:
?
To see where the system sets this initial value, open the file: (explain why in detail later)?
1 |
$ nano /etc/init/rc-sysinit.conf |
You will find such a sentence:?
123 |
# Default runlevel, this may be overriden on the kernel command-line # or by faking an old /etc/inittab entry env DEFAULT_RUNLEVEL= 2 |
Ubuntu init START process Analysis:
The current Linux distros mainstream there are two init modes: One is the widely circulated system V initialization, which comes from UNIX and is still used by various Linux distros, the other is the upstart method proposed in recent years, Based on the event mechanism, all the services of the system, the tasks are event-driven. As far as I know, using the latter way currently has Ubuntu (6.10 and later), Fedora (9.10 and later), Debian (optional). Although the release version with Upstart is not much, it is intended to replace the legacy system V initialization.
As a sort of knowledge, I'm going to summarize the initial process of the two methods here, which is also to facilitate the arrangement of ideas:
before looking for information on the Linux system init process is always able to see Inittab figure, but in my Ubuntu is not this file, until later to know that the use of upstart mode of Ubuntu is not inittab this file. In the legacy system V initialization,/etc/inittab is a fairly important file. It was the first time the init process was started! Inittab is responsible for initializing the system, setting the system runlevel and entering each runlevel corresponding to the command to be executed. Assuming that the default Runlevle set in the current Inittab is 5, init runs the/ETC/INIT.D/RC 5 command, which traverses the scripts/programs in the execution/etc/rc5.d based on the dependencies of the system services. Access to the/ETC/RC5.D directory can be found inside the files are to/etc/init.d/under the corresponding Script/program soft link. Starts with s meaning, begins with K to stop. And the two-digit number behind the s/k represents the start order of the service (determined by the service dependency).
"Note" check the Web, the role of the. d file:. D represents the meaning of the directory as a folder. /etc is the directory where the configuration file is stored, the configuration file is a separate, some kind, Usually a separate configuration file suffix is. conf, a class of configuration files in a directory, the directory name is called XX.D,XX refers to which aspect of the configuration file, such as INIT.D storage for Linux boot configuration files.
So what about the upstart job? We know that the System V Initializaiton is based on RunLevel, based on the init mode of inter-service dependencies, but it is not the key to upstart Job,runlevel although it has an impact on service startup. Upstart job is event-driven, system services start, stop, etc. are determined by the event , in turn, the system service start, stop can also be triggered as an event source other services. And events are not necessarily generated internally by the system, and users can manually type Start/stop [service] to generate events to start/stop the service. Man upstart-evnets to see the events defined by the upstart job, it can be found that runlevel is also treated as an event (events resulting from runlevel changes), and so on, and others such as startup,started, FileSystem and so on. then how does the system service know when it should start and when it terminates? The answer lies in the/etc/init (some distros may be in/ETC/EVENT.D). Enter the/etc/init directory next look, are the system service configuration file, or, is the job definition files. (In fact, upstart Init only needs to/etc/init such a directory, unlike system V init, "turning the foot" to turn a lot of laps to reach the destination, in performance than the former). Open a file, such as cron.conf:
?
12345678910111213141516 |
# cron - regular background program processing daemon
#
# cron
is
a standard UNIX program that runs user-specified programs at
# periodic scheduled times
description
"regular background program processing daemon"
start on runlevel [
2345
]
stop on runlevel [!
2345
] expect fork
respawn
exec cron
|
Believe the keen program apes have found: start on RunLevel [2345];stop on RunLevel [! 2345]
Yes, this is where the configuration file sets up the service when it starts and when it terminates.
In fact, not only at the beginning of the system, at any time during the operation of the system can send events to start or terminate the service. This is one of the advantages of the upstart job, in addition to the system initialization, can also play a role in the system operation phase . In contrast, the configuration file under System V initialization mode is generally used only for the initialization phase of systems, while the system operation phase can be/etc/init.d/service start/stop/ Othercommand to operate the service, but obviously not as concise as the upstart way to understand . (if you are a Linux user, you must not be unfamiliar with these, must be very clear.) )
Well, after introducing system V initialization and upstart, you can now introduce the Ubuntu init system initialization process. Previously mentioned that Ubuntu is using the upstart method of initialization, in fact, not completely, considering the version of the 6.10 prior to the use of system V init and the needs of some services, Ubuntu uses a compatibility mode, namely: System V-style starts the service, also has the upstart to start the service. If you are using Ubuntu11.04 (the system on my current PC), then you can see that there are several directories in the system:
?
123 |
/etc/init /etc/init.d /etc/rc${runlevel}.d |
As both the/ETC/INIT.D,/ETC/RC${RUNLEVEL}.D directory and the/etc/init directory for each of the two init modes are available in Ubuntu, how is ubuntu compatible? In fact, Ubuntu does not use the System V-style boot service directly, knowing that Init in Ubuntu has been replaced with upstart Init, and the system V-style service is stored in/etc/rc${runlevel}. D directory, (while/etc/rc${runlevle}.d/file is a soft link to/etc/init.d) upstart Init does not run directly into it to start the service. It is initiated by indirect calls to this type of service. in other words, the init in Ubuntu does not go directly to/ETC/INIT.D or/etc/rc${runlevel}.d/, it uses a compromise approach, called by some configuration file under/etc/init/etc/rc${ Scripts in runlevel}.d/to start services with legacy system V-style. (This is the essence) Alas, said I feel good around, or see the example bar, see below.
Entering the/etc/init directory (upstart init will read the configuration file in this directory), you will find several configuration files related to RC:
?
123 |
rc.conf rc-sysinit.conf rcS.conf |
Rc-sysinit is started when the startup event occurs, RC is started when the system RunLevel changes, and RCS is started when the system RunLevel is S. As explained in the notes to the configuration file, these files are the key to upstart Init's handling of system v-style services.
Rc-sysinit is started when the startup event occurs, that is, upstart Init reads the rc-sysinit.conf first and executes the relevant configuration and scripts. Rc-sysinit.conf's main work is to set the system default RunLevel, detect the presence of/etc/inittab or kernel command line, if present, set the system in the order of kernel command line >/etc/inittab> default RunLevel RunLevel Finally, call Telinit to enter the set of RunLevel.
The RC service starts (and of course other services will) because the call to Telinit has entered a set Runlevel,runlevel changed event to occur. Then it is necessary for us to see what is in rc.conf. Open rc.conf and note the last line:
?
1 |
exec /etc/init.d/rc $RUNLEVEL |
Does it feel/etc/init.d/rc familiar, yes, in system V initialization, the command line for each runlevel in/etc/inittab is set in this form.
Obviously,/ETC/INIT.D/RC was called and passed the previously set system RunLevel as a parameter. Instead,/ETC/INIT.D/RC invokes the script under/etc/rc${runlevel}.d/(starting with s) based on the incoming runlevel parameter to start the service, terminating the service that is currently in the runlevel that needs to be terminated at the previous runlevel boot. At this point, the process of Ubuntu processing system v-style Services is becoming clearer. Using the Rc-sysinit and RC indirect call/ETC/INIT.D/RC to start the system V-style service, Ubuntu takes care of the legacy system V init with the new upstart init.
The service started in upstart mode has its own profile in the/etc/init/directory, under Terminal type: Initctl list, to see if the services listed are exactly the same as the services under/etc/init/!
Haha, finished.
Transferred from: http://blog.csdn.net/heqiyu34/article/details/18793857
Why isn't Ubuntu/etc/inittab file? Start-up process analysis of Ubuntu