Inter-process relationship

Linux processes have a certain relationship with each other. For example, in the Linux Process base, we can see that each process has a parent process, and all processes take the INIT process as the root to form a tree structure. Here we will explain process groups and sessions to facilitate process management in a richer way.

 

1. Process Group)

Each process belongs to a process group. Each process group can contain multiple processes. The process group has a process group leader. The PID of the process that leads the process (see the Linux Process basics for PID) becomes the process group ID (pgid ), to identify the process group.

$ PS-o pid, pgid, ppid, comm | cat

  PID  PGID  PPID COMMAND17763 17763 17751 bash18534 18534 17763 ps18535 18534 17763 cat

PID is the ID of the process itself, pgid is the ID of the process group where the process is located, and ppid is the parent process ID of the process. From the above results, we can infer the following relationship:

 

The arrows in the figure indicate that the parent process generates child processes through fork and exec mechanisms. PS and CAT are both bash sub-processes. The PID of the Process Group's leading process becomes the process group ID. The lead process can be terminated first. At this time, the process group still exists and holds the same pgid until the last process in the Process Group ends.

 

One important reason we classify some processes into a process group is that we can send signals to a process group. All processes in the process group receive this signal. We will discuss this in depth in the next section.

 

2. Session)

Furthermore, when shell supports job control, multiple process groups can also form a session ). Bash (Bourne-again shell) supports work control, while SH (Bourne shell) does not.

A session is created by a process, which is called a session leader ). The session leader's PID is the session ID ). Each process group in a session is called a job ). A session can have a process to form the foreground work (foreground) of the session, while other process groups work in the background ). Each session can be connected to a control terminal ). When the control terminal has input and output, all are passed to the foreground Process Group of the session. Signals generated by terminals, such as Ctrl + Z and CTRL + \, are transmitted to the foreground process group.

The significance of a session is to include multiple tasks in one terminal and take one of them as the frontend to directly receive the input and output of the terminal and terminal signals. Other tasks are run in the background.

 

A command can be run in the background by adding & at the end:

$ Ping localhost> log &

The terminal displays:

[1] 10141

1 in brackets indicates the work number, and 10141 indicates the pgid.

We can query more detailed information as follows:

$ PS-o pid, pgid, ppid, Sid, tty, comm

(TTY indicates the control Terminal)

 

The signal can be killed

$ Kill-sigterm-10141

Or

$ Kill-sigterm % 1

To the Working Group. In the preceding two commands, one is sent to pgid (by adding-before pgid to indicate a pgid rather than a PID), and the other is sent to work 1 (% 1), which is equivalent to the other two.

 

A job can be changed from working in the background to working in the foreground through $ FG:

$ Cat> log &

$ FG % 1

After we run the first command, we cannot input the command because it is working in the background, until we bring the work to the foreground, we can enter the command to Cat. After the input is complete, press Ctrl + D to notify the shell that the input is complete.

 

The process group concept is easy to understand. Sessions are mainly created for a terminal. When we open multiple terminal windows, we actually create multiple terminal sessions. Each session has its own foreground and background work. In this way, we add a management and operation level for the process. In the era of no graphical interface, sessions allow users to initiate and manage multi-layer processes through shell. For example, I can initiate multiple background jobs through shell, but the standard input and output are not occupied at this time, and I can continue other jobs. Today, graphical interfaces can help us solve this need, but working groups and session mechanisms are still applied in many parts of Linux.