FAQs about Linux signal problems

1. Signal pending and blocking"

Signal status:
The "pending" Status of the signal refers to the period from the generation of the signal to the time before the signal is processed. The "blocking" Status of the signal is a switching action, it indicates that the signal is blocked but not generated.
The example of apue blocks the exit signal with sigprocmask before sleep, then sleep, and generates an exit signal during sleep, but the exit signal is blocked at this time, ("blocking" in Chinese is easy to be misunderstood as a State. It is actually a switch-like action, so "blocked" rather than "blocked ") so it is in the pending status. After sleep, use sigprocmask to turn off the blocking switch of the exit signal, because the exit signal generated previously remains in the pending status. When the blocking switch is closed, exit the "pending" status immediately and get processed. This happens before sigprocmask returns.

Signal lifecycle:
For a complete signal Life Cycle (after the signal is sent to the corresponding processing function for execution), it can be divided into three important stages, which are characterized by four important events: 1. signal generation; 2. the signal is registered in the process. 3. the cancellation of the signal in the process is completed; 4. signal processing function execution is complete. The interval between two adjacent events forms a stage of the signal life cycle.
The following describes the practical significance of the four events:
1. Signal "birth ". The emergence of signals refers to the occurrence of events that trigger signals (such as hardware exceptions, Timer timeouts, and call of the signal sending function kill () or sigqueue ).

2. The signal is "registered" in the target process ";
Data members with pending signals in the task_struct structure of the process:
Struct sigpending pending;
Struct sigpending
{
Struct sigqueue * head, ** tail;
Sigset_t signal;
};
The first and second members point to the beginning and end of a sigqueue-type structure chain (called "pending signal information chain"), and the third member is all pending signal sets in the process, each sigqueue struct in the information chain depicts the information carried by a specific signal and points to the next sigqueue structure:
Struct sigqueue
{
Struct sigqueue * next;
Siginfo_t Info;
};
Signal registration means that the signal value is added to the pending Signal Set of the process (sigset_t signal, the second member of the sigpending structure ), the information carried by the signal is retained to a sigqueue structure of the pending signal information chain. As long as the signal is in the pending Signal Set of the process, it indicates that the process already knows the existence of the signal, but it has not been processed yet, or the signal is blocked by the process.
Note:
When a real-time signal is sent to a process, no matter whether the signal has been registered in the process or not, it will be re-registered. Therefore, the signal will not be lost, real-time signals are also called "reliable signals ". This means that the same real-time signal can occupy multiple sigqueue structures in the pending signal information chain of the same process (each process receives a real-time signal, A structure will be allocated for it to register the signal information, and the structure will be added at the end of the pending signal chain, that is, all generated real-time signals will be registered in the target process );
When a non-real-time signal is sent to a process, if the signal has been registered in the process, the signal will be discarded, resulting in signal loss. Therefore, non-real-time signals are also called "unreliable signals ". This means that the same non-real-time signal occupies at most one sigqueue structure in the pending signal information chain of the process (after a non-real-time signal is generated, (1) if the same signal has been registered in the target structure, it will not be registered. For a process, it is equivalent to not knowing that the current signal occurs and the signal is lost; (2), if the process's pending signals do not have the same signal, register yourself in the process ).

3. logout of the signal in the process. During the execution of the target process, the system checks whether a signal is waiting for processing (this is done every time the system space is returned to the user space ). ("Before sigprocmask is returned, at least one of the pending and unblocked signals will be delivered to the process "???) If a pending signal is waiting for processing and the signal is not blocked by the process, the process will unload the structure occupied by the signal in the pending signal chain before running the corresponding signal processing function. Whether to delete signals from pending processes is different from real-time and non-real-time signals. For non-real-time signals, because only one sigqueue structure is occupied in the pending signal information chain, after the structure is released, the signal should be deleted in the pending Signal Set (the signal is canceled). For real-time signals, multiple sigqueue structures may be occupied in the pending signal information chain, therefore, the number of gqueue-occupied structures should be treated differently: if only one sigqueue structure is occupied (the process only receives this signal once ), then the signal should be deleted from the pending signal set in the process (the signal is canceled ). Otherwise, the signal is not deleted from the pending Signal Set of the process (the signal is canceled ). Before a process executes a signal processing function, it must first cancel the signal in the process.

4. Signal lifecycle termination. After the process cancels the signal, immediately execute the corresponding signal processing function. After the execution is complete, the effect of this sending of the signal on the process is completely ended.
Note:
1) whether the signal is registered is unrelated to the function of sending the signal (such as kill () or sigqueue () and the function of signal installation (signal () and sigaction, it is only related to the signal value (signals whose signal value is smaller than sigrtmin are registered only once at most. signals whose signal value is between sigrtmin and sigrtmax are registered as long as they are received by the process ).
2) when the signal is canceled to the corresponding signal processing function, if the process receives the same signal multiple times, the real-time signal will be registered in the process each time; for non-real-time signals, no matter how many signals are received, only one signal is received and registered only once in the process.

 

No signal numbered 0 exists

Normal signals are not queued, and real-time signals are queued (but generally we don't need them)

Nesting of heterogeneous signals is allowed, that is, an unfinished signal can be embedded into another one;

Nesting of the same signal is not allowed, and the same signal is not queued. Therefore, to prevent signal loss, signal processing must be fast.

 

 

 

2. Signal Processing nesting

Now I have three other processes, a B C.
Process a processes SIGUSR1 and sigusr2:
Sigset (SIGUSR1, A1 );
Sigset (sigusr2, A2 );
If process B first sends a SIGUSR1 to process a, process a enters the A1 () function,
But now the C process sends a siguser2 to the a process, so:
1. Will process a interrupt the processing of A1 () and then proceed to the processing of B1?
2. Process A will first complete A1 () and then respond to sigusr2 entering B1 ()?

Reply:

When a enters the SIGUSR1 signal processing program, if sigusr2 comes
The processing of SIGUSR1 is immediately interrupted and nested into the processing function of sigusr2. After processing sigusr2
Then, it will process SIGUSR1.

Unless you disable sigusr2 in the sa_mask of SIGUSR1,
In this way, the sigusr2 is saved in the queue and can be executed only after the processing of SIGUSR1 is complete.

 

 

 

3. "The signal is logged out in the process. During the execution of the target process, the system checks whether there is a signal waiting for processing (this is done every time the system space is returned to the user space )."?

Signal processing is the first thing to process when the current process is interrupted, from the kernel state to the user State. When the process returns from the kernel state to the user State, first, check whether the process has the signal to be processed (that is, determine the signal bitmap in the process control block of the current process, and block ed to block the bitmap phase, if a bit is found, it indicates that the current process has a signal to be processed. In this case, first determine which of the 32 signals is used, and then the kernel will use the address of the processing function of this signal as the EIP when the kernel returns the user State. Therefore, when the user State is returned, the user-state execution process starts from the signal processing function. After the signal processing function is executed, it is switched to the next statement that is reserved when the interruption occurs.

The process may have no other interruptions, but there will always be clock interruptions. Therefore, when there is a signal to be processed and the starting process is executed, it will be executed when the clock interruption returns.

 

 

 

4. The sigprocmask function returns a problem (zz) for a signal that is no longer blocked)

<Advanced programming in UNIX environment> above:If there is any pending and no blocking signal after calling s I g p r o c m a s k, before S I g P R o C M A S K returns, deliver at least one of them to the process.

The younger brother used the following program to test this sentence: First shield SIGUSR1 and sigusr2 signals, then use the kill function to send them, and then open them.
The running result is:
Sigusr is blocked
SIGUSR1 Function
Sigusr2 Function
SIGUSR1 Function
Sigusr IS Unblocked

Why is the SIGUSR1 function returned twice? Thank you for your answers.

The procedure is as follows:
# Include <stdlib. h>
# Include <signal. h>
Static void sig_usr1 (signo)
{
Printf ("SIGUSR1 function \ n ");
}
Static void sig_usr2 (signo)
{
Printf ("sigusr2 function \ n ");
}
Main ()
{
Sigset_t newmask, oldmask;
If (signal (SIGUSR1, sig_usr1) <0 | signal (sigusr2, sig_usr2) <0)
Perror ("signal \ n ");
Sigemptyset (& newmask );
Sigaddset (& newmask, SIGUSR1 );
Sigaddset (& newmask, sigusr2 );
Sigprocmask (sig_block, & newmask, & oldmask );
Printf ("sigusr is blocked \ n ");
Kill (getpid (), sigusr2 );
Kill (getpid (), SIGUSR1 );

Sigprocmask (sig_setmask, & oldmask, null );
}

Reply: Success :-------------------------------------------------------------------------------------------

Signal is an unreliable signal function with a "Time Window" vulnerability.
The specific process is as follows:

When the sigprocmask function is called to release the signal shielding function, the system checks the signals in sequence. Note that this sequence is not the order of the signals, but the order of the signal values, that is, 1-64;
When SIGUSR1 is checked, a signal is generated and enters the signal handle of SIGUSR1. The kernel creates a function stack for this handle function in the user space because the signal handle function is in the user space, all can be interrupted during execution. after entering the sigusr2 handle function, clear the sigusr2 signal suspension mark and check the signal suspension. It is found that the SIGUSR1 signal suspension mark is still available, create a sequential handle for it and execute it (if it only returns the interrupted location of SIGUSR1, it will be printed only once ??), After the execution, clear the flag and return to the user space. Execute the function as normal. If the function stack is not executed, execute the function.

Set the function handle with sigaction.
Struct sigaction act1, Act2;
Act1.sa _ handler = sig_usr1;
Sigemptyset (& act1.sa _ mask );
Act2.sa _ handler = sig_usr2;
Sigemptyset (& act2.sa _ mask );
Sigaction (SIGUSR1, & act1, null );
Sigaction (sigusr2, & Act2, null );
Why is there no such problem with sigaction ??

I am also confused about this issue. Although SIGUSR1 has been executed twice, it seems that the same stack is executed. I have not studied it carefully. the above comments are for reference only .??????

------------------------------- Supplement:

If you call sigprocmask to release a blocked signal, and any suspended signal is blocked, at least one of these signals will be delivered before sigprocmask returns.

 

 

 

4. apue2 Reading Notes (2): Why do the sigchld signal need to be used when the wait function family is available:

First of all, let's talk about the meaning of zombie processes in UNIX, as defined in apue2:
In UNIX system terminology, a process that has terminated, but whose parent has not yet waited for it, is called a zombie.
That is to say, any child process whose parent process does not call the wait function to obtain the termination state of the child process is a zombie process after termination. The key to this concept is whether the parent process has called the wait function.

In regard to the sigchld signal, apue2 also says:
Whenever a process terminates or stops, the sigchld signal is sent to the parent. by default, this signal is ignored, so the parent must catch this signal if it wants to be notified whenever a child's status changes. the normal action in the signal-catching
Function is to call one of the wait functions to fetch the child's process ID and termination status.
Simply put, when a child process exits, the parent process receives a sigchld signal, which is ignored by default, the conventional method is to call the wait function in the signal processing function to obtain the exit status of the sub-process.

There is a question here. Since the wait function family needs to be called in the sigchld signal processing function, why does the wait function family still need to use the sigchld signal?

We know that unix citic is a mechanism for asynchronous processing of something, like saying that you are going to do something. Before you go, tell the neighbor Zhang San that if Li Si comes to you, he will be notified, this allows you to pull out and do this, and when Li Si really visits you, someone will inform you that this is a more vivid metaphor of asynchronous signals.

Generally, the parent process has two situations after the child process is generated. One is that the parent process continues to do other things, as shown in the preceding example, the other is that the parent process does nothing and keeps exiting the wait sub-process. the sigchld signal is prepared for this first scenario. It allows the parent process to do something else, as long as the parent process registers a function to process the signal, this function is called when the sub-process exits. In the function, the wait sub-process is terminated before continuing to do the parent process.

That is to say, clarify the following points:
1) Any child process that does not call the wait function family to obtain the termination state of the child process will become a zombie process upon exit.
2) The sigchld signal can asynchronously notify the parent process that a child process exits.

 

Summary:

Waitpid does not rely on the arrival of sigchld to determine whether the sub-process exits. However, if the sigchld processing function is set, it is necessary to wait for the occurrence of the sigchld signal and complete the signal processing function, waitpid can receive the exit status of the sub-process. In the system () Implementation of apue, The sigchld signal is blocked, but the signal processing function is not set. Therefore, the waitpid can still return normally when the sigchld is blocked, because sigchld does not affect the work of waitpid when no signal processing function is set. Why is the sigchld signal blocked? That is to prevent other programs (in addition to calling system and using other programs) from setting the sigchld signal processing function. If other programs set the sigchld signal processing function, before waitpid waits for the return of the subroutine, it must process the sigchld signal processing program. If the signal is blocked, it will not process the signal processing program to prevent redundant information from appearing in system.

For example, while (waitpid (PID, & status, 0) <0) does not use sigchld, but the parent process continuously checks whether the child process PID is terminated, that is, the parent process is not notified by the subprocess of the asynchronous signal mechanism, but is continuously queried by the parent process.

 

5. Conclusion:

If the signal is interrupted and returned, the system checks whether the signal needs to be processed. The signal processing function is executed in the user State. The original signal processing function is executed, and the new signal is generated and interrupted (for example, the clock is interrupted ), then the new signal will preemptively nest the original signal processing function (when there is no blocking ).

 

 

 

6. Questions:

Pause () is returned as long as a signal processing program returns, so nested signal processing functions return pause, instead of waiting until the outermost signal processing function returns ?? In this case, use pause to implement sleep. When the nested signal processing function returns, pause returns, sleep returns, and calls the sleep function for execution, so the nested external signal processing function will never be executed ??