A probe into the------of Linux signals

Objective

Linux executes the program in the process unit. We can treat the computer as a building, the kernel (kernel) is the building's administrator, the process is the building's tenants. Each process has a separate room (which is part of the process's memory space), and each room is not allowed to be accessed by anyone outside the process. In this way, each process focuses only on what it does, regardless of other processes, and does not allow other processes to see the inside of their room. This is a protection mechanism for each process. (Imagine how confusing hundreds of processes are always interfering with each other, or hundreds of processes peeping into one another ...)

However, in some cases, we need to break the closed room in order to exchange information with the process. For example, the kernel discovers that a process is hitting a wall (a hardware error) and needs to make the process aware that it will ruin the entire building. Again, for example, we want to work with multiple processes. In this way, we need certain means of communication. A signal (signal) is a way of passing information to a process. We can think of the signal as the manager of the building stuffing a little note in the mailbox of the room. Then the process takes out the small note, will be based on the contents of the note to take certain actions, such as the lamp is broken, reminding the process to use a flashlight. (Of course, you can completely ignore this note, but in an emergency such as fire, ignoring the signal is not a good option). Compared to other inter-process communication methods (interprocess communication, for example, pipe, shared memory), the signal can be transmitted more coarse information, just an integer. But it is because of the small amount of information transmitted, the signal is also easy to manage and use. Signals are therefore frequently used for system management related tasks, such as notification process finalization, abort, or recovery, and so on.

The signal is managed by the kernel (kernel). The signal is produced in a variety of ways, it can be generated by the kernel itself, such as a hardware error (such as a division operation with a denominator of 0, or a segmentation fault), the kernel needs to notify a process, or it can be generated by other processes, sent to the kernel, and then passed to the target process by the kernel. Each process in the kernel has a table that stores relevant information (the room's mailbox). When the kernel needs to pass a signal to a process, it writes the signal (with a slip of paper) in the appropriate place in the table corresponding to the process, thus generating (generate) the signal. When the process executes a system call, exiting the kernel after the system call completes, the message is checked in the mailbox. If there is a signal, the process executes the action on the Signal (signal action, also called signal processing signal disposition), which is called the execution (deliver) signal. The signal is in the waiting (pending) state (the note has not been viewed) from the signal generation to the time of the signal's transmission. We can also design the program to block some of the signals it generates, that is, to keep the signals waiting until the process cancels the block (unblock) or ignores the signal.

Common signals

Each integer transmitted by the signal is given a special meaning, and a signal name pair should be an integer. Common signals are SIGINT, Sigquit, Sigcont, SIGTSTP, SIGALRM and so on. These are the names of the signals. can be done by

$man 7 Signal

To check for more signals.

SIGINT when the keyboard presses CTRL + C to signal from the shell, the signal is passed to the process running in the foreground of the shell, and the default action that should signal is to interrupt (INTERRUPT) the process.

Sigquit when the keyboard presses ctrl+\ to signal from the shell, the signal is passed to the process in the shell that is running in the foreground, and the process is exited (quit) on the default action that should be signaled.

SIGTSTP when the keyboard presses CTRL + Z to send a coarse signal from the shell, the signal is passed to the process running in the foreground of the shell, and the default action that should be signaled is to pause (STOP) the process.

The Sigcont is used to notify the paused process to continue.

The SIGALRM acts as a timer, usually a program that generates the signal after a certain amount of time.

Using signals in the shell

Let's actually use the signal below. We run ping in the shell:

$ping localhost

At this point we can pass the SIGTSTP to the process via CTRL + Z. Shown in the shell:

[1]+  Stopped                 ping localhost

We use $ps to query the PID of the ping process (PID is the room number of the ping process), which is 27397 in my machine

We can send a signal to a process in the shell through the $kill command:

$kill-sigcont 27397

To pass the sigcont signal to the ping process.

Signal processing (signal disposition)

In the example above, all signals are given the default action of the corresponding signal. But that's not absolute. When the process decides to execute the new Hudson, there are several possibilities:

1) ignoring (ignore) signal, the signal is cleared, the process itself does not take any special action

2) default operation. Each signal pair should have a certain default action. For example the above sigcont is used to continue the process.

3) Custom action (DIY): Also called get (catch) signal. The action that corresponds to the signal is preset in the execution process.

What kind of action the process takes, based on the process's programming. In particular, when getting signals, programs tend to set up some long and complex operations (typically putting these operations into a function).

The signal is often used for system management, so its content is quite complex. In-depth understanding of signals requires a certain knowledge of Linux environment programming.

(Non-original, content originated from the Internet)

A probe into the------of Linux signals