For the startup process of linux, it has been studied until the kernel runs /sbin/init and starts the first user process. Because this part has always been working in the kernel mode, it is still helpful for learning the kernel. At that time, /sbin The process after /init also needs to be understood, and I will summarize it today.
First, roughly write the process of the kernel from booting to executing /sbin/init:
head.S ===> start_kernel ===> rest_init ===> cpu_idle and kernel thread init ===> init_post ===> /sbin/init
The general process after init is executed is:
init ===> fork out getty Open the corresponding terminal according to /etc/inittab ===> exec Execute login to verify the user and password According to /etc/passwd ===>The password is correct, set some environment variables to set the home directory exec execute bash
getty login bash is the same process
A problem I encountered before at work was that after the client machine entered the console normally, sudo su could not obtain superuser privileges, saying not in sudoer.
Sudo su uses ordinary user passwords to obtain super user permissions, but not all ordinary users can use sudo su to obtain super user permissions. The specific authorization is in /etc/sudoers. That is to say, we use sudo su when obtaining the superuser authority. At this time, the system goes back to sudoers to check whether the application user is in the list. If so, the user obtains the superuser authority, and then the user has the superuser authority for a period of time. , the length of time is also defined in /etc/sudoers
This analysis means that the user on the client machine is not in the sudoers list, and can be added to the list with the adduser command, but adding sudoers requires superuser privileges. . . This forms an infinite loop!
The solution that comes to mind is to use the parameter init=/bin/bash when the kernel is started, so that instead of executing init after the kernel is started, it skips the init gettty login and executes bash directly. In this case, the login is not executed, and the system does not enable any user. , this is the console is the super user authority, this is to use the command adduser to add the user to the sudoer, so that the ordinary user can obtain the super user authority
After logging in to the Linux system, you will find (using the "top" or "ps -ax" command) that the original getty process of your terminal is no longer found. Because the getty process executes the login program, it is replaced by the login process, and finally by your login shell process.
When you type your username at the "login:" prompt, getty reads the username and executes the login procedure, passing it the username information as well. So the getty process is replaced by the login process. The login process will then ask you to enter a password. After the password check is passed, the program recorded in the /etc/passwd file corresponding to your username will be executed. Usually this program is the bash shell program. Therefore, the original getty process was eventually replaced by a bash process, and the corresponding three programs all have the same process ID.
When logging out (log out), all processes on the terminal will be terminated (killed), including the login shell process bash. Therefore, for a getty program listed in the /etc/inittab file, once the bash program it is replaced by is terminated or exited, the init process will recreate a getty process for the corresponding terminal.
The login program is mainly used to require the login user to enter a password. According to the user name entered by the user, it obtains the login item of the corresponding user from the password file passwd, and then calls getpass() to display the "password:" prompt, reads the password entered by the user, and then uses the encryption algorithm to perform the password operation. Encrypted and compared with the pw_passwd field in the user entry in the password file. If the password entered several times by the user is invalid, the login program will exit with error code 1, indicating that the login process failed. At this time, the wait() of the parent process (process init) will return the pid of the exiting process, so a child process will be created again according to the recorded information, and the agetty program will be executed again for the terminal device in the child process, repeating the above Process.
The login program can also be executed as a command under the shell by the user during operation. At this point it can be used to switch from one user to another at any time. If no parameters are given during execution, login will display a prompt for entering a user name. If the user is not a superuser (root), and a file named nologin exists in the /etc/ directory, the information in the file will be displayed and the login process will be terminated.
If special access restrictions are specified for this user in the /etc/usertty file, these restrictions must be met. If a superuser, the login tty device used must be specified in the /etc/securetty file.
After all these conditions are met, login also asks the user for a password and checks it. If .hushlogin exists, login performs a "quiet" login process, i.e. does not check for mail, does not display the last login time and information in the motd file. Otherwise, if the /var/log/lastlog file exists, the last login time in it will be displayed.
If the password entered by the user is correct, the login will change the current working directory (Currend Work Directory) to the starting working directory of the user specified in the password file. And modify the access rights of the terminal device to user read/write and group write, and set the group ID of the process. Then use the obtained information to initialize environment variable information such as home directory (HOME=), shell program used (SHELL=), username (USER= and LOGNAME=) and default path sequence for system executables (PATH=) . Then display the text information in the /etc/motd file (message-of-the-day), and check and display whether the user has mail information. Finally, the login program changes to the user ID of the logged in user and executes the shell program specified in the user entry in the password file, such as bash or csh.
If the user entry in the password file /etc/passwd does not specify which shell program to use, the system will use the default /bin/sh program. If the user's home directory is not specified in the password file, the system will use the default root directory /. For a description of some execution options and special access restrictions of the login program, see the online manual page (man 8 login) in Linux systems.
A shell program is a complex command-line interpreter program that is executed when a user logs in to the system for interactive operations. It is where the user interacts with the computer. It takes the information entered by the user and then executes the command. Users can interactively input directly to the shell on the terminal, or input to the shell interpreter using a shell script file. In Linux systems, the commonly used shells are:
Bourne Again Shell,/bin/bash
C shell, /bin/csh (or tcsh)
BSD shell/bin/ash（或bsh）
During the login process, the system (login) will know which shell program should be executed for the user from the last field of the user's corresponding login item in the password file.
A language with flow control structures is implemented in shell programs and is widely used. At present, these shell programs are all developing towards being compatible with IEEE POSIX 1003.2, so although they each have their own characteristics, their basic functions have become more and more similar. This book mainly introduces the working principle and implementation mechanism of bash, and the implementation mechanism of other shells is similar.
When the login starts to execute the shell during the login process, the first character of the parameter argv[0] is '-', indicating that the shell is executed as a login shell. At this time, the shell program will perform some operations corresponding to the login process according to the character. The login shell will first read and execute commands from the /etc/profile file and the .profile file (if it exists). If the ENV environment variable is set when entering the shell, or the variable is set in the .profile file of the login shell, the shell will read the command from the file named by the variable and execute it in the next step. Therefore, users should put the commands to be executed each time they log in in the .profile file, and put the commands to be executed each time the shell is run in the file specified by the ENV variable. The way to set the ENV environment variable is to place the following statement in the .profile file in your home directory.
ENV=$HOME/.anyfilename; export ENV
When executing the shell, in addition to some specified optional options, if command-line parameters are also specified, the shell will treat the first parameter as a script file name and execute the commands in it, while the rest of the parameters are treated as are the positional arguments of the shell ($1, $2, etc.). Otherwise the shell program will read commands from its standard input.
There are many options available when executing a shell program, see the online man page for sh in Linux systems for instructions.