Linux Start-up process

Nanyi

Six months ago, I wrote, "How does a computer start?" To explore the role of BIOS and master boot records.

The article does not cover the operating system and is only relevant to the Board's onboard program. Today, I would like to write down and discuss what happens when the operating system takes over the hardware, that is, the startup process of the operating system.

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

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

First step, load kernel

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

Take My computer as an example, the/boot directory below is probably some of these files:

$ 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 initialized with the system environment.

Since 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 level of operation

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

One of the major tasks of the Init process is to run these boot-up programs. However, different applications need to start different programs, such as when serving as a server, the need to start Apache, as a desktop is not required. Linux allows different start-up programs to be assigned for different occasions, which is called "RunLevel" (runlevel). That is, at startup, depending on the runlevel, determine which programs to run.

Linux presets seven RunLevel (0-6). In general, 0 is shutdown, 1 is single-user mode (that is, maintenance mode), and 6 is a reboot. Run level 2-5, the distribution is different, for Debian, is the same multi-user mode (that is, Normal mode).

The INIT process first reads the file/etc/inittab, which is the run-level settings file. If you open it, you can see that the first line is this:

　　id:2:initdefault:　　

The value of Initdefault is 2, indicating that the operating level at system startup is 2. If you need to specify a different level, you can modify this value manually.

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

 /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 above directory name represents the Run command (running the program) and the last D indicates directory. Let's look at what programs are specified in the/ETC/RC2.D directory.

　　$ ls  /etc/rc2.d　　　　README　　S01motd　　S13rpcbind　　S14nfs-common　　S16binfmt-support　　S16rsyslog　　S16sudo　　S17apache2　　S18acpid　　...　　

You can see that in addition to the first file Readme, other filenames are "letters s+ two-digit + program name" form. The letter S means start, that is, the starting point (the start script runs with start), if the position is the letter K, which means kill (close), that is, if you switch from another runlevel, you need to close the program (the startup script has a run parameter of stop). The next two digits indicate the processing order, the smaller the number, the earlier processing, so the first program to start is MOTD, then rpcbing, NFS ... When the numbers are the same, they start in alphabetical order of the program name, so the Rsyslog will start before sudo.

All files in this directory (except for the readme) are the programs to be loaded 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 (see here and here).

Fourth step, load boot Start program

As mentioned earlier, the seven preset "RunLevel" each have a directory that stores the programs that need to start up. It is not difficult to think that if more than one "runlevel" needs to start the same program, then the program's startup script will have a copy in each directory. This can be a management problem: if you want to modify the startup script, do you want to change every directory?

The Linux solution, is the seven/ETC/RCN.D directories listed in the program, are set as a link file, pointing to another directory/ETC/INIT.D, the real startup scripts are unified in this directory. The init process loads the start-up program, which is actually running the startup script in this directory.

Here's what the link file really points to.

$ 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 -> .< Span class= "token punctuation".　　/init.d/apache2 S18acpid -> ./init.d/acpid  

Another benefit of this is that 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, to restart the Apache server, run the following command:

/etc/init.d/apache2 restart　　

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

Fifth Step, User login

After the boot loader has finished loading, the user will be logged in.

In general, there are three ways users sign in:

(1) Command line login

(2) SSH login

(3) Graphical interface login

In all three cases, users are certified in their own way.

(1) Command line login: The init process calls the Getty program (meaning get teletype), allowing the user to enter a user name and password. Once the input is complete, call the login program and check the password (Debian will run an identity check/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: Then the system calls the SSHD program (Debian will run/etc/pam.d/ssh again), replacing Getty and Login, and then start the shell.

(3) GUI Login: The init process invokes the display manager, the Gnome graphical interface corresponds to the display manager for GDM (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's session.

Sixth step, enter login shell

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

The default shell for Debian is bash, which reads into a series of configuration files. There are also differences in the three cases of the previous step, which are dealt with in this step.

(1) command line login: first read into the/etc/profile, which is a valid configuration for all users, and then look for the following three files, which is the configuration for the current user.

　　~/.bash_profile　　~/.bash_login　　~/.profile　　

It is important to note that these three files are no longer read into the file as long as they exist. For example, if ~/.bash_profile exists, it will not be read into the next two files.

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

(3) GUI login: Only load/etc/profile and ~/.profile. In other words, ~/.bash_profile will not run, whether or not it is.

Seventh step, open Non-login shell

To be honest, after the last step, the Linux startup process is finished, and the user can already see the command line prompt or the graphical interface. However, for the sake of completeness of the content, this step must be introduced again.

Once the user enters the operating system, a shell is often opened manually. This shell is called the Non-login shell, which means it differs from the shell that appears when logging in, and does not read configuration files such as/etc/profile and. Profile.

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

You might ask, if you don't get into the non-login shell, wouldn't it be. BASHRC won't run, so bash can't finish customizing? In fact, Debian has taken this into account, please open the file ~/.profile and see the following code:

 if [-n  "$ Bash_version "]; then if [-f "  $HOME/.BASHRC "]then  " $HOME/.BASHRC" fi fi             

The above code first determines whether the variable $BASH _version has a value, and then determines if 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 it is also possible to run a file as "source ~/.BASHRC".

Therefore, as soon as you run the ~/.profile file, the ~/.BASHRC file runs. However, as mentioned in the first case in the previous section, if a ~/.bash_profile file exists, it is possible that the ~/.profile file will not run. It is easy to solve this problem by writing the following code. Bash_profile.

　　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 this file.

Bash's setup is so cumbersome that it's caused by historical reasons. In the early days, the computer was running slowly, and loading the configuration file took a long time, and the bash author had to split the configuration file into sections and load it in stages. The general settings of the system are placed in the/etc/profile, and the user's personal, settings that need to be inherited by all child processes are placed in the. Profile, which does not require the inherited settings to be placed in the. bashrc.

By the way, besides Linux, the shell used by Mac OS X is also bash. However, it only loads. Bash_profile, and then calls. BASHRC inside. Bash_profile. And, whether it's SSH login or launching the shell window in a graphical interface, this is the case.

Reference links

[1] Debian Wiki, Environment Variables

[2] Debian Wiki, Dot Files

[3] Debian administration, an introduction to Run-levels

[4] Debian Admin,debian and Ubuntu Linux Run levels

[5] Linux Information Project (linfo), Runlevel Definition

[6] linuxquestions.org, what is run levels?

[7] Dalton Hubble, Bash configurations demystified