Orphan Process Group and Terminal Session Overview

Orphan Process: A process whose parent process has terminated. The orphan process is updated by the init process <; Adoption", the init process ID is 1, so the parent process of the adopted orphan process is updated to 1.

Orphaned Process Group: The parent process of all processes in a process group is either a process of the process group or a process in the session in which the process group is located. The condition that a process group is not an orphan process group is that there is one process in the group whose parent process is in another group belonging to the same session.

GNU explains why the aortic process group, its terminal becomes free and a new session can be established on it. (In fact, another user could log in on the terminal .. could could a problem if any processes from the old session are still trying to use that terminal.To prevent problems, process groups that continue running even after the session leader has terminated are marked as orphaned process groups.When a process group becomes Ordinarily, this causes the processes to terminate. However, if a program ignores this signal or establishes a handler for it, it can continue running as in the orphan process group even after its controlling process Terminates; but it still cannot access the terminal any more.

When a terminal control process (ie, the session first process) terminates, then the terminal can be used to establish a new session. This may create a problem in which any process in the old session (a collection of one or more process groups) can access the terminal again. In order to prevent such problems from arising, there is a concept of an orphan process group. When a process consists of an orphan process group, posix.1 requires a SIGHUP (suspend) signal to be sent to the process in the orphan process group. The default processing for this signal is to terminate the process, but if you ignore this signal or If it is handled separately, then the suspended process can continue to execute.

The following excerpt from the network:

The problem of the terminal involves several concepts, that is, process groups, sessions, and operations, which are described separately below. A session consists of a series of processes that are organized into process groups according to different execution contents. All processes in a session must be descendants of the session leader process, thus ensuring that these processes are the leader of the session. The process is directly or indirectly opened. Only in this way can the processes be guaranteed to be within the line of sight of the session leader process. At the same time, the orphan process group is no longer controlled by the session leader process. Homework: There is only one terminal, but there are many things to do at the same time, or at least to do it in a timely manner. You can't do one thing before you do another. What should I do? After all, after starting a process, the process will monopolize the terminal. After all, the shell will set it as the foreground process group process. This is the function of the job, just add a & symbol after a command, for example, I want to execute x, then type: x & shell results are: [1] 1234 where 1234 is the process Pid, and 1 is the id of the job, so the x does not occupy the terminal, the shell can start other processes or jobs, for example, start the job 2: [2] 4321 think of the job 1 need to use the terminal Enter some information, then use: fg %1 to put job 1 in the foreground (currently there is only one process in job 1), how to put the job placed in the foreground into the background? Only need to use the SIGSTOP signal to stop the process of using the terminal in the foreground, and then the process will let go of the terminal occupying the process group: one job is a process group, and a separate process can monopolize a process group or join another session of the same session. The process group must meet the condition that all processes in the same process group must be descendants of a session. The so-called process group is to organize the work or organize the same kind of tasks. Control terminal: The creator of a session has the right to apply for a control terminal, in which standard input can be accepted, a control shortcut that the shell understands can be sent, a job can be created and the job control function provided by the session header process can be used. The control terminal can only be created by the session header process, and the control terminal is exclusive. As long as one process regards one terminal as the control terminal, other processes cannot do this regardless of who it is. The last few lines in tty_open are available. Code if (!noctty &&current->signal->leader &&!current->signal->tty &&tty->session == 0) {task_lock(current) ;current->signal->tty=tty;task_unlock(current);current->signal->tty_old_pgrp = 0;tty->session = current->signal->session; //Set sessiontty ->pgrp = process_group(current);} It can be seen that other processes are not authorized to apply for control terminals. Who is this control terminal usually used for? The most unsuccessful session leader applied for the terminal, because if he is even suspected, the children who belong to him later are questionable. The terminal for the application of the head is for the children. The heads will use these children. It is divided into several process groups, and one group is designated as the foreground process group. Only the process of this foreground process group can use the control terminal. Bash generally exists as the session leader. bash will create a process group for an executed command. When it accepts a command to be executed, it will set the process to the foreground process group. It accepts the command line and adds & The command will create a job and set it as a background process group, then who is the front desk, bash yourself. The background process can't use the terminal. If you use & to execute a process with a function such as getchar, it will receive the SIGTTIN signal, but you can use the fg command to bring such a process to the foreground. Control process: Obviously, the first control process is the head process of a session. In addition, even the session leader can only control other processes through the terminal. The so-called control is to send signals instead of operating memory, which is also between processes. A way of communication. So the so-called control process is the process of applying to the control terminal. (Operation control is similar) Orphan process group: There are orphan processes, and there are also concepts of orphan process groups. Why introduce the concept and the introduction of this concept requires the OS implementer to do something? First look at the two premise, first, posix uses a concept of session to describe a user's login and the user's operation after the login, and then use the concept of the job to describe the content of different operations, and finally use the concept of the process to describe different A specific job in the operation; secondly, Unix initially organized all the processes into a tree form, which makes it easy to track each process and manage it easily. (Thinking, human political society is also a tree-like structure: monarchy , two-house system, etc.). With the above two premise things, I understand that everything is for management. Everything is for the security of the logged-in user. That is, the logged-in user's job cannot be controlled by the next logged-in user, even if their users. The same name is also not acceptable, so the so-called orphan process group is simply to break away from the session control that created it, the process group leaving its session eyeliner, how to control the process in Unix, how to prove whether it is in their own eyeliner, that is The tree structure, as long as the process of the subtree rooted in itself is the process within the eyeliner, the process is protected and has the right to operate, and the process on other branches is in principle untouchable ( I also want to talk about the creation of remote threads of windows, but then I have to say that its complex token mechanism, otherwise windows fans are not convinced, so do not say it, Unix build process using fork, naturally such a & ldquo "Fork" formed a branch of one's own, of course, in their own eyeliner, generally a session for the logged-in user starts at After the second login, as long as the user does not logout, all non-daemon processes executed on the shell of the terminal are descendants of the shell, so they form a session, all in the eyeliner of the shell, and a session ends in The death of the session leader (note: the termination of the process group is independent of the termination of the leader process). Now consider the scenario after the shell exits on the terminal. According to the regulations, all the processes on the terminal are successively given to other processes. Most of the cases are init processes, and then another user logs in to the terminal or knows the previous one. Another person with a bad idea who logs in to the user key logs in to the terminal. Of course, a new session is created for the shell that was started. Since the previously logged in user has logged out, the user who logged in now is due to the previous user's process group. It becomes an orphan process group, so it can't control them anymore. The members of those orphan process groups either continue to run safely or are killed by the SIGHUP signal sent by the shell when they exit. The POSIX rule is iron discipline, and the implementation of Unix or Linux, whether it is the kernel or the shell, is a discipline-based approach. Iron discipline requires job control to be based on session, that is, it cannot operate in other sessions. Process group, so the commands like fg and bg can't operate the orphan process, so what if the background process group is stopped by the SIGSTOP signal because the read/write terminal is stopped, and then it becomes a member of the orphan process group? The job control command of other sessions can't operate it anymore. Even if ps -xj finds it and then sends SIGCONT manually, then it can't use the terminal. This is another discipline requirement of POSIX. Only the session associated with the terminal is unique. The process in the foreground process group can use the terminal, so as long as a shell exits, the best way is to kill all the processes in its session, so the original intention of SIGHUP is this, but you can completely ignore this signal or yourself. Define the response to this signal. The basic limitation of POSIX is that the session ID cannot be set because it is the protected basic unit, but the ID of the process group can be set. After all, it only distinguishes between the impossible jobs, and the PID of the last process cannot be set. Because it is the intrinsic property of the process, it forms the key attribute of the tree structure structure. POSIX defines the orphan process group: the parent process of a process without a process belongs to the same session but different process groups. Daemon: The daemon needs to do a few things: 1.fork a child process: Since bash will set the program as a foreground process group process between fork and exec when executing the program, the fork will not be set up after this. , then the child process will become a background process, and there is no exclusive process group, the child process belongs to the process group of the parent process. 2. Call setsid to start a new session and start a new process group, which becomes the head of a new session. 3. Fork a child process again, this can avoid the child process of the first fork re-apply to control the terminal, after all, it is the session leader. 4. Close all file descriptors, especially close the terminal-related descriptors 0, 1, 2, etc., because there is no terminal. 5….