Linux system startup process detailed

The article does not involve the operating system, only related to the board's onboard program. Today, I want to go on to write about what happens after the OS takes over the hardware, which is the operating system startup process.

This part is more interesting. Because in the BIOS phase, the behavior of the computer is basically written dead, the programmer can do not many things, but once into the operating system, programmers can almost customize all aspects. So, this part is more closely related to the programmer.

My main concern is the Linux operating system, which is the current server-side mainstream operating system. The following is for the Debian release because I am not familiar with other distributions.

The first step, loading the kernel

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

Take My computer for example, the/boot directory is probably 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 two, start the initialization process

After the kernel file is loaded, it starts running the first program/sbin/init, which is the initialization of the system environment.

Because Init is the first program to run, its process number (PID) is 1. All other processes derive from it, all of which are its child processes.

Step three, determine the run level

Many programs need to boot up. They are called "services" in Windows, and are called "Daemons" in Linux (daemon).

One of the big tasks of the Init process is to run these boot-up programs. However, different occasions need to start different programs, such as when used as a server, you need to start Apache, as a desktop does not need. Linux allows different startup programs to be allocated for different occasions, which is called "Run Level" (RunLevel). That is, at startup, depending on the run level, determine which programs to run.

Linux presets seven run levels (0-6). Generally speaking, 0 is shutdown, 1 is Single-user mode (that is, maintenance mode), 6 is reboot. Run level 2-5, different distributions, is the same multiuser mode (that is, Normal mode) for Debian.

The INIT process first reads the file/etc/inittab, which is the setup file for the run level. 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 the Initdefault is 2, which indicates that the system started at a 2 run level. If you need to specify a different level, you can modify this value manually.

So, what are the procedures for running level 2, and how does the system know which programs should be loaded at each level? ...... The answer is that each run level below the/ETC directory has a corresponding subdirectory that specifies the program to load.

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 directory name above indicates the Run command (running the program), and the last D represents the directory (directory). Let's take a look at exactly what 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, other than the first file readme, other file names are "letter s+ two-digit + program name" form. The letter S denotes start, which is the meaning of startup (the startup script's run parameter is start), and if that position is the letter K, it means kill (off), that is, if you switch from another run level, the program you want to close (the startup script's run parameter is stop). The following two digits indicate the order of processing, the smaller the number the earlier processing, so the first startup program is MOTD, then rpcbing, NFS ... When the numbers are the same, they start in alphabetical order by program name, so Rsyslog starts in sudo first.

All the files in this directory (except the Readme) are the programs to load at startup. If you want to add or remove some programs, it is not recommended to manually modify the/ETC/RCN.D directory, preferably with some special commands to manage (refer to here and here).

Fourth step, load boot up program

As mentioned earlier, the seven preset "run levels" each have a directory that holds the programs that need to be started. It's not hard to imagine that if multiple "run levels" need to start the same program, the startup script for the program will have a copy in each directory. This can be a management problem: if you want to modify the startup script, does every directory have to be changed?

The solution to Linux is that the programs listed in the seven/ETC/RCN.D directories are set as linked files, pointing to another directory/etc/init.d, and the real startup scripts are all unified in this directory. The init process loads the boot program one at a while, in fact, runs the startup script in this directory.

The following is the real point of the link 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 benefit of doing this is if you want to manually shut down or restart a process, go directly to the directory/ETC/INIT.D to find the startup script. For example, I'm going to reboot the Apache server and run the following command:

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

/ETC/INIT.D This directory name the last letter D, which is the meaning of directory, means that this is a directory used to differentiate from the program/etc/init.

Step Fifth, User login

After the boot loader has finished loading, the user must log in.

Generally speaking, there are three kinds of user login methods:

The code is as follows	Copy Code
(1) Command line login (2) SSH login (3) Graphical interface login

These three kinds of situations, all have their own way to authenticate the user.

(1) Command line login: The init process invokes the Getty program (meaning get teletype), allowing the user to enter a username and password. After the input is complete, call the login program and check the password (Debian will run an identity check program/etc/pam.d/login). If the password is correct, read the user-specified shell from the file/etc/passwd and start the shell.

(2) SSH login: When the system calls the SSHD program (Debian will also run/etc/pam.d/ssh), replace Getty and Login, and then start the shell.

(3) Graphical interface login: The init process calls the display manager, the Gnome graphical interface display manager for GDM (Gnome display manager), and then the user enters a username and password. If the password is correct, read the/etc/gdm3/xsession and start the user's session.

Step sixth, enter login shell

The so-called shell, simply speaking is a command-line interface, so that users can directly talk to the operating system. The shell that is opened when the user logs on is called the login shell.

The Debian default shell is bash, which reads a series of configuration files. The previous step of the three cases in this step of processing, there are also differences.

(1) command line login: Read/etc/profile First, this is a valid configuration for all users, and then look for the following three files, which is for the current user's configuration.

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

It should be noted that these three files are no longer read as long as one exists. For example, if ~/.bash_profile exists, it will not read back two files.

(2) SSH login: Exactly the same as the first case.

(3) Graphical interface login: Only load/etc/profile and ~/.profile. That is to say, ~/.bash_profile, whether or not, will not run.

Step seventh, open the Non-login shell.

To be honest, after the last step, the Linux startup process is over, and the user can already see the command line prompt or the graphical interface. However, in order to complete the content, we must introduce this step.

Once the user has entered the operating system, it will often manually open a shell. This shell is called the non-login shell, meaning it is different from the shell that appears when you log on, and does not read/etc/profile and. Profile profiles.

The importance of non-login shell is not only that it is the shell the user most often touches, but also that it reads the user's own bash profile ~/.BASHRC. Most of the time, our customization of bash is written in this file.

If you don't get into the non-login shell, you might ask, wouldn't it be. BASHRC will not run, so bash will not be able to complete customization? In fact, Debian has already taken this into account, please open the file ~/.profile and 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 determines whether the variable $BASH _version has a value, and then determines whether there is a. bashrc file in the home directory and runs the file if it exists. The point at the beginning of the third line is the shorthand form of the source command, which means that running a file, written as "source ~/.BASHRC", is also possible.

Therefore, as long as the ~/.profile file is run, the ~/.BASHRC file will be run. However, the first case in the previous section mentions that if there is a ~/.bash_profile file, the ~/.profile file may not be running. The solution to this problem is simple, write the following code to the. Bash_profile on the line.

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

This way, in either case, the. BASHRC will execute, and the user's settings can be safely written to the file.

The settings for bash are so cumbersome that they are caused by historical reasons. In the early days, when the computer was running slowly, loading the configuration file took a long time, the author of Bash had to split the configuration file into several parts and load it in stages. The general settings of the system are placed in the/etc/profile, and the user's individual settings, which need to be inherited by all child processes, are placed in. Profile, and no inherited settings are placed on the. BASHRC.

Incidentally, the shell used by Mac OS X is also bash, in addition to Linux. However, it only loads. Bash_profile, and then calls. BASHRC in. Bash_profile. And, whether it's an SSH login or a shell window that starts in a graphical interface, it's all the same.