Explain the startup process of Linux system after startup

Time:2022-1-7

In fact, the startup process of Linux is very similar to that of windows, but we can’t see the startup information on windows. When Linux starts, we will see a lot of startup information, such as whether a service is started or not.

The startup process of Linux system can be divided into five parts: kernel boot; Run init; System initialization; Establish the terminal; The user logs into the system.

A kernel boot

When the computer is powered on, the first is BIOS power on self-test, which starts according to the boot device (usually hard disk) set in BIOS. Then the grub program on the boot device starts to boot Linux. When the boot program successfully completes the boot task, Linux takes over the control of the CPU from them, and then the CPU starts to execute the core image code of Linux and starts the Linux startup process. That is, the so-called kernel boot starts. In fact, the kernel boot process is very complex. We regard it as a black box. Anyway, the Linux kernel has done some work. Finally, the kernel calls and loads the init program. So far, the kernel boot is completed. To the next protagonist, init.

B run init

Init process is the starting point of all processes in the system. You can compare it to the ancestor of all processes in the system. Without this process, no process in the system will start. The init program first needs to read the configuration file / etc / inittab. Inittab is a non executable text file, which consists of several lines of instructions. The details are as follows: (you can execute the command cat / etc / inittab on your Linux)

  

Copy code

The code is as follows:

# inittab This file describes how the INIT process should set up
  # the system in a certain run-level.
  #
  # Author: Miquel van Smoorenburg,
  # Modified for RHS Linux by Marc Ewing and Donnie Barnes
  #
  # Default runlevel. The runlevels used by RHS are:
  # 0 – halt (Do NOT set initdefault to this)
  # 1 – Single user mode
  # 2 – Multiuser, without NFS (The same as 3, if you do not havenetworking)
  # 3 – Full multiuser mode
  # 4 – unused
  # 5 – X11
  # 6 – reboot (Do NOT set initdefault to this)
  #
#### indicates that the current default operation level is 5 (initdefault);
  id:5:initdefault:
#### automatically execute / etc / rc d/rc. Sysinit script (sysinit)
  # System initialization.
  si::sysinit:/etc/rc.d/rc.sysinit
  l0:0:wait:/etc/rc.d/rc 0
  l1:1:wait:/etc/rc.d/rc 1
  l2:2:wait:/etc/rc.d/rc 2
  l3:3:wait:/etc/rc.d/rc 3
  l4:4:wait:/etc/rc.d/rc 4
#### when the run level is 5, run / etc / RC. With 5 as the parameter D / RC script, init will wait for it to return (wait)
  l5:5:wait:/etc/rc.d/rc 5
  l6:6:wait:/etc/rc.d/rc 6
#### during startup, it is allowed to press ctrl-alt-delete to restart the system
  # Trap CTRL-ALT-DELETE
  ca::ctrlaltdel:/sbin/shutdown -t3 -r now
  # When our UPS tells us power has failed, assume we have a few minutes
  # of power left. Schedule a shutdown for 2 minutes from now.
  # This does, of course, assume you have powerd installed and your
  # UPS connected and working correctly.
  pf::powerfail:/sbin/shutdown -f -h +2 “Power Failure; System Shutting Down”
  # If power was restored before the shutdown kicked in, cancel it.
  pr:12345:powerokwait:/sbin/shutdown -c “Power Restored; Shutdown Cancelled”
#### at levels 2, 3, 4 and 5, execute the / SBIN / mingetty program with ttyx as the parameter, and open the ttyx terminal for user login,
#### if the process exits, run the mingetty program (respawn) again
  # Run gettys in standard runlevels
  1:2345:respawn:/sbin/mingetty tty1
  2:2345:respawn:/sbin/mingetty tty2
  3:2345:respawn:/sbin/mingetty tty3
  4:2345:respawn:/sbin/mingetty tty4
  5:2345:respawn:/sbin/mingetty tty5
  6:2345:respawn:/sbin/mingetty tty6
#### run XDM program at level 5, provide XDM graphical login interface, and re execute when exiting (respawn)
  # Run xdm in runlevel 5
  x:5:respawn:/etc/X11/prefdm -nodaemon

Take the inittab file above as an example to illustrate the format of inittab. The line starting with # is the comment line. Except for the comment line, each line has the following format:
  

Copy code

The code is as follows:

id:runlevel:action:process

The above items are explained in detail as follows:

1. id

ID refers to the entry identifier, which is a string. For other login program items such as Getty or mingetty, the ID is required to be the same as the number of TTY, otherwise the Getty program will not work normally.
2. Runlevel

Runlevel is the identification of the running level init is at. Generally, 0-6 and s or s are used. Operation levels 0, 1 and 6 are reserved by the system: 0 is the shutdown action, 1 is the restart to single user mode, and 6 is the restart; S and s have the same meaning. They mean single user mode and do not need inittab file, so they do not appear in inittab. In fact, when entering single user mode, init directly runs / SBIN / sulogin on the console (/ dev / console). In general system implementation, levels 2, 3, 4 and 5 are used. In CentOS system, 2 represents multi-user mode without NFS support, 3 represents full multi-user mode (also the most commonly used level), 4 is reserved for user customization, and 5 represents XDM graphical login mode. 7-9 levels can also be used. These levels are not defined in traditional UNIX systems. Runlevel can be multiple values in parallel to match multiple run levels. For most actions, it will be executed only when runlevel matches the current run level successfully.
3. action
Action describes how subsequent processes run. The desirable values of action include: initdefault, sysinit, boot, bootwait, etc.: initdefault is a special action value used to identify the default startup level; When init is activated by the core, it will read the initdefault item in the inittab, get the runlevel, and use it as the current running level. If there is no inittab file, or there is no initdefault entry in it, init will request runlevel on the console. Sysinit, boot, bootwait and other actions will run unconditionally at system startup, ignoring runlevel. Other actions (excluding initdefault) are related to a runlevel. The definition of each action is described in detail in the man Manual of inittab.
4. process
Process is a specific execution program. The program can be followed by parameters.

Tips: if you don’t understand this file, it doesn’t matter. With your in-depth understanding of Linux, you will suddenly see the light when you look back at this file. But now you have to understand the meaning of runlevel at all levels.

C system initialization

There is a line in the init configuration file: Si:: sysinit: / etc / RC d/rc. Sysinit, which calls and executes / etc / RC d/rc. Sysinit, while RC Sysinit is a bash shell script, which mainly completes some system initialization, RC Sysinit is an important script that must be run first at every run level. It mainly completes the following tasks: activating the switching partition, checking the disk, loading hardware modules and other tasks that need to be performed first.

rc. Sysinit has about 850 lines, but each single function is relatively simple and annotated. It is recommended that interested users can read the file on their machine to understand the details of system initialization. Because this file is long, it is not listed in this article or introduced in detail. When RC After the sysinit program is executed, it will return to init to continue to the next step. Usually, it will be executed to / etc / rc D / RC program. Taking runlevel 3 as an example, init will execute the following line in the configuration file inittab:
  l5:5:wait:/etc/rc.d/rc 5
This line indicates running / etc / RC. With 5 as the parameter d/rc,/etc/rc. D / RC is a shell script that accepts 5 as a parameter to execute / etc / RC d/rc5. D / directory, / etc / RC d/rc5. These startup scripts in the D / directory are actually connection files rather than real RC startup scripts. The real RC startup scripts are actually placed in / etc / RC d/init. D / directory. These RC startup scripts have similar usage. They can generally accept start, stop, restart, status and other parameters.

/etc/rc. d/rc5. The RC startup script in D / is usually a connection file starting with K or S. for the startup script starting with s, it will be run with the start parameter. If it is found that there are corresponding scripts and connections starting with K, and they are already running (marked by the file under / var / lock / subsys /), these started daemons will be stopped with the stop parameter first, and then run again. This is done to ensure that all related daemons will restart when init changes the run level.

As for which daemons will run in each run level, users can set from the line through “system services” in chkconfig or setup.

D establish terminal

After RC is executed, init is returned. At this time, the basic system environment has been set up and various daemons have been started. Init will then open six terminals so that users can log in to the system. The following six lines in inittab define six terminals:
  

Copy code

The code is as follows:

1:2345:respawn:/sbin/mingetty tty1
  2:2345:respawn:/sbin/mingetty tty2
  3:2345:respawn:/sbin/mingetty tty3
  4:2345:respawn:/sbin/mingetty tty4
  5:2345:respawn:/sbin/mingetty tty5
  6:2345:respawn:/sbin/mingetty tty6

 
It can be seen from the above that the mingetty program will be run in respawn mode at the operation levels of 2, 3, 4 and 5. The mingetty program can open the terminal and set the mode. At the same time, it will display a text login interface, which is the login interface we often see. In this login interface, the user will be prompted to enter the user name, and the user entered by the user will be passed to the login program as a parameter for verification
ID card of the user.

E user login system

For graphical users with run level 5, their login is through a graphical login interface. After successful login, you can directly enter window managers such as KDE and gnome. This article mainly talks about text login: when we see the login interface of mingetty, we can enter the user name and password to log in to the system.

The account verification program of Linux is login. Login will receive the user name from mingetty as the user name parameter. Then login will analyze the user name: if the user name is not root and there is a / etc / nologin file, login will output the contents of the nologin file and exit. This is usually used to prevent non root users from logging in during system maintenance. Only the terminals registered in / etc / securety allow root to log in. If this file does not exist, root can log in on any terminal/ The / etc / usertty file is used to impose additional access restrictions on users. If this file does not exist, there are no other restrictions.

After analyzing the user name, login will search / etc / passwd and / etc / shadow to verify the password and set other information of the account, such as what the home directory is and what shell to use. If no home directory is specified, it will default to the root directory; If no shell is specified, it defaults to / bin / bash.

After the login program succeeds, it will output the last login information to the corresponding terminal (recorded in / var / log / lastlog) and check whether the user has a new email (under the corresponding user name directory of / usr / spool / mail /). Then start setting various environment variables: for bash, the system first looks for the / etc / profile script file and executes it; Then, if the user’s home directory exists bash_ Profile file, execute it, and other configuration files may be called in these files. After all configuration files are executed, various environment variables are also set. At this time, the familiar command line prompt will appear, and the whole startup process is over.

Recommended Today

Springboot 2.6.3 integrated redis stepped on the pit

The integration steps are as follows: development tools: idea2019, JDK1.8, maven 3.5.4 Idea creates a new project, selects spring initializer, selects spring boot version 2.6.3 (the latest version at present), and adds web, and redis modules. After successful construction, the POM file is as follows: <?xml version=”1.0″ encoding=”UTF-8″?> <project xmlns=”http://maven.apache.org/POM/4.0.0″ xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” xsi:schemaLocation=”http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd”> <modelVersion>4.0.0</modelVersion> <parent> […]