Linux Startup Process

This article introduces the process of starting a Linux system.

That article does not involve the operating system, but is only related to the onboard program of the motherboard. Today, I want to continue writing about what happened after the operating system took over the hardware, that is, the operating system startup process.

This part is interesting. In the BIOS stage, the computer behavior is basically written to death, and there are not many tasks that programmers can do. However, once they enter the operating system, programmers can customize almost all aspects. Therefore, this part is more closely related to programmers.

I am mainly concerned about the Linux operating system, which is currently the mainstream operating system on the server side. The following content is for the Debian release, because I am not familiar with other releases.

Step 1: load the kernel

After the operating system takes over the hardware, it first reads the kernel files under the/boot directory.

Take my computer as an example. The/boot directory contains the following files:

The Code is as follows:	Copy code
$ ls /boot　　　　config-3.2.0-3-amd64　　config-3.2.0-4-amd64　　grub　　initrd.img-3.2.0-3-amd64　　initrd.img-3.2.0-4-amd64　　System.map-3.2.0-3-amd64　　System.map-3.2.0-4-amd64　　vmlinuz-3.2.0-3-amd64　　vmlinuz-3.2.0-4-amd64

Step 2. Start the initialization process

After the Kernel File is loaded, it starts to run the first program/sbin/init. Its function is to initialize the system environment.

As init is the first program to run, its process ID (pid) is 1. All other processes are derived from it and are its sub-processes.

Step 3: Determine the running level

Many programs need to be started. They are called "services" in Windows and daemon in Linux ).

A major task of the init process is to run these boot programs. However, different programs need to be started in different scenarios. For example, Apache needs to be started when used as a server. Linux allows different boot start programs to be assigned for different occasions, which is called "runlevel ). That is to say, at startup, determine the programs to run according to the "running level.

There are seven preset Linux running levels (0-6 ). Generally, 0 indicates shutdown, 1 indicates single-user mode (maintenance mode), and 6 indicates restart. Running Level 2-5, different releases, for Debian, are the same multi-user mode (that is, the normal mode ).

The init process first reads the/etc/inittab file, which is a runtime-level setting file. If you open it, you can see that the first line is like this:

The Code is as follows:	Copy code
id:2:initdefault:

The value of initdefault is 2, indicating that the running level is 2 at system startup. If you want to specify another level, you can manually modify this value.

So what programs are there in Level 2? How does the system know which programs should be loaded at each level ?...... The answer is that each running level has a subdirectory under the/etc directory, specifying the program to be loaded.

The Code is as follows:	Copy code
/etc/rc0.d　　/etc/rc1.d　　/etc/rc2.d　　/etc/rc3.d　　/etc/rc4.d　　/etc/rc5.d　　/etc/rc6.d

The "rc" in the preceding directory name indicates run command, and the last d Indicates directory ). Next, let's see which programs are specified in the/etc/rc2.d directory.

The Code is as follows:	Copy code
$ ls /etc/rc2.d　　　　README　　S01motd　　S13rpcbind　　S14nfs-common　　S16binfmt-support　　S16rsyslog　　S16sudo　　S17apache2　　S18acpid　　...

As you can see, except for the first file README, other file names are in the form of "letter S + two-digit characters + program name. The letter S indicates Start, which means start (the running parameter of the startup script is Start). If the position is K, it indicates Kill (disabled ), that is, if you switch from another running level, you need to close the program (the running parameter of the startup script is stop ). The two digits below indicate the processing order. The smaller the number, the earlier the processing, so the first program to be started is motd, and then rpcbing, nfs ...... if the numbers are the same, the program is started alphabetically by the program name. Therefore, rsyslog is started prior to sudo.

All files in this directory (except README) are the programs to be loaded at startup. If you want to add or delete some programs, it is not recommended to manually modify the/etc/rcN. d directory. It is best to use some special commands for Management (refer to here and here ).

Step 4. Load the Startup Program

As mentioned above, the seven preset "Running levels" each have a directory to store programs that need to be started. It is easy to think that if multiple "Running levels" need to start the same program, the startup script of this program will have a copy in each directory. This will cause management troubles: If you want to modify the startup script, wouldn't every directory have to be changed?

The solution for Linux is seven/etc/rcN. all programs listed in the d directory are set as linked files and point to another directory/etc/init. d. All the real startup scripts are stored in this directory. The init process loads the boot programs one by one, which is actually the startup script in this directory.

The following figure shows the real point of the linked file.

The Code is as follows:	Copy code
$ ls -l /etc/rc2.d　　　　README　　S01motd -> ../init.d/motd　　S13rpcbind -> ../init.d/rpcbind　　S14nfs-common -> ../init.d/nfs-common　　S16binfmt-support -> ../init.d/binfmt-support　　S16rsyslog -> ../init.d/rsyslog　　S16sudo -> ../init.d/sudo　　S17apache2 -> ../init.d/apache2　　S18acpid -> ../init.d/acpid　　...

Another advantage of this is that if you want to manually close or restart a process, you can directly search for the startup script in the/etc/init. d directory. For example, to restart the Apache server, run the following command:

The Code is as follows:	Copy code
$ sudo /etc/init.d/apache2 restart

/Etc/init. d: The last letter d in the directory name. It indicates a directory, which is used to distinguish it from Program/etc/init.

Step 5. User Logon

After the Startup Program is loaded, the user must log on.

Generally, there are three logon methods:

The Code is as follows:	Copy code
(1) command line Logon (2) ssh Logon (3) graphic interface Logon

All three cases have their own methods to authenticate users.

(1) command line Logon: The init process calls the getty Program (Meaning get teletype) to allow the user to enter the user name and password. After entering the information, call the login program and check the password (Debian will run another identity verification program/etc/pam. d/login ). If the password is correct, read the shell specified by the user from the file/etc/passwd and start the shell.

(2) ssh Logon: The system calls the sshd Program (Debian will run/etc/pam. d/ssh again), replace getty and login, and then start the shell.

(3) graphic interface Logon: The Display Manager called by the init process. The Display Manager corresponding to the Gnome graphic interface is the GNOME Display Manager. Then, the user enters the user name and password. If the password is correct, read/etc/gdm3/Xsession and start the user session.

Step 6: Enter login shell

Shell is a command line interface that allows users to directly talk to the operating system. The shell opened when a user logs on is called the login shell.

The default shell of Debian is Bash, which reads a series of configuration files. There are also differences in the three situations in the previous step.

(1) log on through the command line: first read/etc/profile, which is a configuration that is valid for all users; then find the following three files in sequence, which is the configuration for the current user.

The Code is as follows:	Copy code
~/.bash_profile　　~/.bash_login　　~/.profile

Note that as long as one of the three files exists, they will not be read into the subsequent files. For example ~ /. Bash_profile does not read the last two files.

(2) ssh Logon: This is the same as the first scenario.

(3) graphic interface Logon: only load/etc/profile and ~ /. Profile. That is to say ,~ /. Bash_profile does not run whether or not it is available.

Step 7: Open the non-login shell

To be honest, after the previous step is completed, the Linux Startup Process is over, and you can see the command line prompt or graphical interface. However, to complete the content, you must introduce this step.

After a user enters the operating system, a shell is often started manually. This shell is called non-login shell, which means that it is different from the shell that appears during logon and does not read configuration files such as/etc/profile and. profile.

The importance of non-login shell lies not only in the shell most frequently accessed by users, but also in the fact that it reads the user's own bash configuration file ~ /. Bashrc. Most of the time, bash customization is written in this file.

You may ask, if you don't enter the non-login shell, isn't it. bashrc won't run, So bash won't be able to complete customization? In fact, Debian has taken this issue into consideration. open the file ~ /. Profile, you can see the following code:

The Code is as follows:	Copy code
if [ -n "$BASH_VERSION" ]; then　　　　if [ -f "$HOME/.bashrc" ]; then　　　　　　. "$HOME/.bashrc"　　　　fi　　fi

The code above first checks whether the variable $ BASH_VERSION has a value, and then checks whether the. bashrc file exists in the main directory. If yes, runs the file. The point starting with the third line is a short form of the source command, indicating to run a file and write it as "source ~ /. Bashrc "is also possible.

Therefore, you only need to run ~ /. Profile file ,~ The/. bashrc file will run together. However, as mentioned in the first case in the previous section, if ~ /. Bash_profile file, so it may not run ~ /. Profile file. To solve this problem, write the following code to. bash_profile.

The Code is as follows:	Copy code
if [ -f ~/.profile ]; then　　　　. ~/.profile　　fi

In this way, in either case,. bashrc will be executed, and user settings can be safely written to this file.

The reason why Bash settings are so cumbersome is due to historical reasons. In the early days, the computer was running very slowly and it took a long time to load the configuration file. The author of Bash had to divide the configuration file into several parts and load them in stages. The general settings of the system are stored in/etc/profile. The user's personal settings that need to be inherited by all sub-processes are placed in. profile, and those that do not need to be inherited are placed in. bashrc.

By the way, in addition to Linux, the shell used by Mac OS X is also Bash. However, it only loads. bash_profile and then calls. bashrc in. bash_profile. In addition, this is true for both ssh logon and shell window startup in the graphic interface.