a process is a core concept of the operating system. Each process has its own unique identity: The process ID, and its own life cycle. The life cycle of a typical process is shown in 4-1.
The process has a parent process, and the parent process has a parent process, which forms a family tree rooted in the init process. In addition, processes have other hierarchical relationships: processes, process groups, and sessions. Process groups and sessions form a level two hierarchy between processes: A process group is a collection of related processes, and a session is a collection of related groups of processes. In this way, a process will have the following id: PID: Unique identification of the process. For multithreaded processes, all threads call the Getpid function to return the same value. Pgid: Process group ID. Each process will have a process group ID that represents the process group to which the process belongs. By default, newly created processes inherit the process group ID of the parent process. SID: Session ID. Each process also has a session ID. By default, the newly created process inherits the session ID of the parent process. You can call the following directives to see the hierarchy of all processes:
ps -ejHps axjf
Process, you can call the following function to get the process group ID and the session ID.
pid_t getpgrp ( pid_t getsid(pid_t pid);
As mentioned earlier, the new process inherits the process group ID and session ID of the parent process by default, and if it is the default, all processes should have a common process group ID and session ID. But call PS AXJF can see that this is not the case, there are many different sessions in the system, there are different process groups under each session.
Why is it so? Just like a family business, if from the beginning of the business, all the family members are stereotyped and disciplined, by default, there will only be a company, a department. But also some "rebellious" children, willing to open up for the family company, willing to set up a new department. These new departments are the newly created process groups. If a children "deviant", or even unwilling to stay in the family company, he did not open the world, another company, the new company is the newly created conversation group. Thus, the system must have to change and set the process group ID and session ID function interface, otherwise, there will only be a session, a process group. Process groups and sessions are concepts introduced to support shell job control. When a new user logs on to Linux, the logon process creates a session for the user. The user's logon shell is the first process of the session. The first process ID of the session is the ID of the entire session. A session is a collection of one or more process groups that contains all the activities of the logged-on user. When you log in to the shell, the user might use a pipeline that allows multiple processes to work together to complete a task that is part of the same process group. When the user is connected to Linux via the SSH client tool (putty, Xshell, etc.), the logon scenario is similar to the one above. 4.2.1 Process Group
The interface for modifying the process group ID is as follows
int Setpgid pid_ T pid , pid_t Pgid );
The meaning of this function is to find a process with a process ID of PID, modify its process group ID to Pgid, and if the PID has a value of 0, it means to modify the process group ID of the calling process. This interface is typically used to create a new process group.
The following three interfaces have a consistent meaning, creating a new process group, and the specified process becomes the first process of the process group. If the parameter PID and Pgid values do not match, then the Setpgid function migrates a process from the group of processes that originally belonged to the pgid corresponding process group.
setpgid(0,0) getpid (), 0 )setpgid(getpid(),getpid())
The Setpgid function has many limitations:
The pid parameter must be specified as a process that calls the Setpgid function or its child processes, and cannot arbitrarily modify the process group ID of the unrelated process, and if this rule is violated, 1 is returned, and the errno is Esrch. The pid parameter can specify the child process of the calling process. However, the child process cannot modify the process group ID of the child process if it has already executed the EXEC function. If this rule is violated, 1 is returned and errno is eaccess. • Move between process groups, call processes, PID-specified processes and target process groups must be within the same session. This is a good understanding, do not join the company (session), will not be able to join the company's subordinate departments (process group), or the department to rebel rhythm. If this rule is violated, 1 is returned, and errno is set to Eperm. PID The specified process cannot be the session first process. If this rule is violated, 1 is returned, and errno is eperm.
With the interface that creates the process group, the newly created process group does not have to inherit the process group ID of the parent process. The most common scenario for creating a process group is to execute a pipeline command in the shell, with the following code:cmd1 | CMD2 | cmd3
The following is a simple command to illustrate the relationship between its processes as shown in 4-2.
ps ax|grep nfsd Both the PS process and the grep process are child processes created by bash, both of which work together through a pipeline that is subordinate to the same process group, where the PS process is the leader of the process group. The concept of a process group is not difficult to understand and can be used to compare the relationship between people. Colleagues who work together are naturally more intimate than irrelevant passers-by. The process of working together in the shell belongs to the same process group, just as the person working together belongs to the same department. The concept of a process group was introduced to make it easier to manage this set of processes. For example, this job is abandoned, no need to send a signal to each process one by one, you can directly send the signal to the process group, all processes in the process group will receive the signal. As mentioned earlier, once a child process executes exec, the parent process cannot call the Setpgid function to set the process group ID of the child process, which affects the shell's job control. For insurance reasons, the general parent process calls the Setpgid function to set the process group ID of the child process after calling fork to create the child process, and the child process also calls the Setpgid function to set its own process group ID. These two invocations are redundant at one time, but this ensures that either the parent process executes first or the child process is executed first, and the child process must have entered the specified process group. Because the order of execution of the parent-child process is indeterminate after the fork, if you do not do so, you will not be able to determine whether the child process has entered the corresponding process group within a certain time window. Users can execute multiple commands at the same time in the shell. For long-running commands (such as compiling large projects), the user does not have to wait for the command to complete before executing the next command. When a user executes a command, it can add a "&" symbol at the end of the command, indicating that the command is placed in the background. The process group that corresponds to this command is the background process group. At any one time, multiple background process groups may exist at the same time, but there can be only one foreground process group at any given time. Only processes in the foreground process group can read input from the control terminal. When the user generates terminal characters (such as CTRL + C, CTRL + Z, ctr+\, etc.) in the terminal input signal, the corresponding signal will only be sent to the foreground process group. There can be more than one process group in the shell, whether it is a foreground process group or a background process group, they are more or less connected, and in order to better control these groups of processes (or jobs), the system introduces the concept of a session. The meaning of the session is to include a lot of work in one terminal, choose one as the foreground to receive the terminal's input and signal directly, the other work is placed in the background execution.
A session session is a collection of one or more process groups, with the user logging into the system as an example, there may be 4-3 cases.
The system provides the SETSID function to create the session with the following interface definition:
#include <UNISTD.H> pid_t setsid(void);
If the calling process for this function is not the process group leader, then calling the function will take the following things: 1) Create a new session, which is equal to the process ID, and the calling process becomes the session's first process. 2) Create a process group, the process group ID equals the process ID, and the calling process becomes the leader of the process group. 3) The process does not control the terminal, and if the process has a control terminal before calling Setsid, the connection will be broken off. The process calling the SETSID function cannot be the leader of the process group, otherwise the call fails, returns 1, and the errno is eperm. This restriction is more reasonable. If the process group leader is allowed to migrate to a new session, and the other members of the process group are still in the old session, then the process of the same process group will be in a different session, which destroys the strict hierarchical relationship between the process group and the session.
From for notes (Wiz)
Basic concepts of the process of the Linux kernel (process, process group, session relationship)
