Process Group Session Linux process Groups and Sessions

In Unix-like systems, users typically deal with a variety of related processes. Although there is only one terminal process (the user's login shell , which launches various programs and services through the shell) at login time, many related processes are usually generated shortly thereafter, such as the following:

• Run non-interactive programs in the background (for example, "&" in the Bash command)
• Switch between various interactive processes through the Shell's job control
• Start a group of programs through a pipeline
• Enable multiple terminal windows in a graphical environment (e.g. X Window System)

To manage these processes, the kernel groups these processes, calling them process groups , and several process groups forming a single session . Examples are shown, ls and less in a process group, and grep wc in a process group. The two process groups also belong to one session.

The following is a detailed talk about process groups and sessions.

1.1 Process Groups

Each process belongs to a "process group", and when a process is created, it defaults to the member of the group in which the parent process is located. Traditionally, the group ID (pgid) of a process equals the first member of the group (also known as the process Group leader ).

You can use ps j this command to get the process's PPID (parent process ID), PID (this process id), PGID (process group ID) and SID (session ID).

[email protected]:~$ ps j PPID   PID  PGID   SID TTY      TPGID STAT   UID   TIME COMMAND24120 24125 24125 24125 pts/5    24125 Ss+   1000   0:00 bash24120 30633 30633 30633 pts/6    31468 Ss    1000   0:00 bash30633 31468 31468 30633 pts/6    31468 R+    1000   0:00 ps j

When using a shell that does not have work management (Job control) (for example ash ), each shell creates a child process that is in the same process group and session as the shell. When using a shell with work management (for example bash ), if you are using pipelines (refer to: Pipes:a Brief Introduction), then these pipes are joined together by a process group, and the shell is in a single session. For example:

% cat paper | ideal | pic | tbl | eqn | ditroff > out

These programs run after the process is in a process group inside.

Foreground Process Group

A maximum of one process group per session is the "foreground process group", and the control terminal (the second section below) passes the inputs and signals to the members of the process group (for example, if you press CTRL + C at the terminal, the SIGINT signal is sent to the foreground process group). The process can obtain the tcgetpgrp(fd) foreground process group ID of the session, which corresponds to the file descriptor of the session's control terminal, through the system call, fd or by setting the file descriptor of the session's tcsetpgrp(fd,pgrp) foreground process group, which corresponds to the fd session's control terminal, pgrp is a group of processes in this session.

So how do you get fd it? The ctermid() call returns the name of the control terminal, which returns the file on a POSIX compliant system, /dev/tty and then we can open the file with a system call to open() get the file descriptor.

Background Process Group

In a single session, process groups other than the foreground process group are called "background process groups", and the processes of those background process groups do not participate in the terminal's input and output, and if they attempt to read data from the terminal, they receive SIGTTIN a signal (their default action is stop) and the terminal notifies the user:

SIGTTIN   21,21,26    Stop    Terminal input for background process

However, if the background process ignores or SIGTTIN blocks the signal, or if the process group it is in is an "orphan process Group" (which is said below), then the read terminal will get a Eio (Error in operation) error instead of receiving a SIGTTIN signal. When a background process attempts to write to the terminal, it may be SIGTTOU signaled:

SIGTTOU   22,22,27    Stop    Terminal output for background process

Similarly, if the background process ignores or SIGTTOU blocks the signal, or if the process group it is in is an "orphan process Group", then the read terminal gets a Eio (error in operation) error instead of receiving a SIGTTOU signal.

In order for the background process to join the foreground process group, you can use the fg command.

Appropriate action

You can setpgid() join a process to another process group through a system call:

int setpgid(pid_t pid, pid_t pgid);

This pid is the process to be manipulated, 0 represents the process, the process pgid group to join, and 0 for the process group to be joined is the PID of the process (that is, the group leader of this group is the process). Pgid

setpgid()note the following points to use:

1. A process may be pgid set to itself or to other members of its group, and such operations may not alter the process group of any other process, even if the process has root privileges.
2. The conversation process (Part II Introduction) cannot change the group of processes in which it is located.
3. A process cannot be joined to a process group in another session, in other words, setpgid it can only be used in one session. Because the setpgid() process can only be "moved" in this session, two sessions cannot have the same process group or process.

A process can obtain the ID of its own group by system call, or the group ID of the getpgrp() getpgid(p) group where PID is P, and, when P is 0 o'clock, the group ID of the process:

pid_t getpgid(pid_t pid)

pid_t getpgrp(void)

The following is a simple example diagram:

Disconnect (I do not understand the Linux terminal, Shell communication mechanism, this place temporarily affixed to the source of the original text, later understand the translation)

If The terminal goes away by modem hangup, and the line were not local, then a SIGHUP are sent to the session leader. Any further reads from the gone terminal return EOF. (Or possibly-1 with errno set to EIO.)

If The terminal is the slave side of a pseudotty, and the master side are closed (for the last time), then a SIGHUP is sent To the foreground process group of the slave side.

When the session leader dies, a SIGHUP are sent to all processes in the foreground process group. Moreover, the terminal stops being the controlling terminal of this session (so that it can become the controlling Termina L of another session).

Thus, if the terminal goes away and the session leader is a job control shell, then it can handle things for its Descendan TS, e.g. by sending them again a SIGHUP. If on the other hand the session leader be an innocent process this does not catch SIGHUP, it'll die, and all foreground Processes get a SIGHUP.

1.2 Orphan Process Group

Now let's talk about how the process terminates when the session disappears.

Suppose there is a session running under the terminal, which will conversation be a shell. When this shell is present, the process group in the session is in a different environment, may be running, or may be suspended. When the terminal shuts down, if it is running, it cannot be read in or out after the terminal is closed, and if it is suspended, it may never be awakened (nor terminated). In this case, the process group of the original session is called the Orphan process group. The parent process that POSIX defines as the process group is also a member of the process group or a member of another session. in summary, as long as the parent process of a process group is in a different group of the same session, it is not an orphan process group.

When a process is made up of an orphan process group, each process in the process group is sent a signal- SIGHUP usually the process will be shut down normally. For SIGHUP a signal to be received, the selected non-terminating program will be sent one SIGCONT , and this signal will restart any pending processes. This signal flow can close most processes and ensure that the remaining processes are running (not suspended).

When the process is "abandoned", it is forced and the control terminal is separated (other users can use this terminal). The original session ID continues to be retained (not as the PID of the neonatal process) until the program exits in each session.

2.1 Sessions

When a user logs off, the kernel terminates all the processes that the user started before (otherwise these processes will be running and waiting for the input to arrive). To simplify this task, the kernel sets up several process groups and is a "session". The ID of the session is the PID of the setsid() process that initiated the session (that is, the first process of the session, usually the user's shell), which is also known as "conversation", and the subsequent generation of all descendant processes is defaulted to this session.

The process can also use to leave its own setsid session, whose parameters are empty, returning the ID of the new session:

#include <unistd.h>pid_t setsid(void);

2.2 Control Terminal

Each session has and only one corresponding terminal, the session process from the terminal to get input and output, the terminal is called "Control Terminal" (controlling terminal). This terminal may be the local console of the machine, the pseudo-terminal of the desktop environment, the pseudo terminal on the network and so on.

Although the control terminal for a session can be changed, this is usually set by the process that initializes the user's login environment.

Main references:

1. The Process Model of Linux application development
2. Processes (with a brief introduction to processes and threads)
3. The third edition of in-depth understanding of computer systems

Process Group Session Linux process Groups and Sessions