A brief discussion on Linux signal mechanism

1. Signal List

root@ubuntu:# kill -l

1) SIGHUP 2) SIGINT 3) SIGQUIT 4) SIGILL 5) SIGTRAP

6) SIGABRT 7) SIGBUS 8) SIGFPE 9) SIGKILL 10) SIGUSR1

11) SIGSEGV 12) SIGUSR2 13) SIGPIPE 14) SIGALRM 15) SIGTERM

16) SIGSTKFLT 17) SIGCHLD 18) SIGCONT 19) SIGSTOP 20) SIGTSTP

21) SIGTTIN 22) SIGTTOU 23) SIGURG 24) SIGXCPU 25) SIGXFSZ

26) SIGVTALRM 27) SIGPROF 28) SIGWINCH 29) SIGIO 30) SIGPWR

31) SIGSYS 34) SIGRTMIN 35) SIGRTMIN+1 36) SIGRTMIN+2 37) SIGRTMIN+3

38) SIGRTMIN+4 39) SIGRTMIN+5 40) SIGRTMIN+6 41) SIGRTMIN+7 42) SIGRTMIN+8

43) SIGRTMIN+9 44) SIGRTMIN+10 45) SIGRTMIN+11 46) SIGRTMIN+12 47) SIGRTMIN+13

48) SIGRTMIN+14 49) SIGRTMIN+15 50) SIGRTMAX-14 51) SIGRTMAX-13 52) SIGRTMAX-12

53) SIGRTMAX-11 54) SIGRTMAX-10 55) SIGRTMAX-9 56) SIGRTMAX-8 57) SIGRTMAX-7

58) SIGRTMAX-6 59) SIGRTMAX-5 60) SIGRTMAX-4 61) SIGRTMAX-3 62) SIGRTMAX-2

63) SIGRTMAX-1 64) SIGRTMAX

The most common ones are:

• Ctrl + C triggers SIGINT;
• Ctrl + \ triggers SIGQUIT;
• However, it should be noted that Ctrl + D does not trigger a signal, but generates an EOF, which is why pressing this combination in Python interactive mode will exit Python.

1.1. Real-time signal and non-real-time signal

As above, kill lists all signals. Real-time signals and non-real-time signals are also called reliable signals and unreliable signals. SIGRTMIN and those after it are real-time signals, and those before it are non-real-time signals. The difference is that real-time signals support repeated queuing, but non-real-time signals do not. By default, non-real-time signals will only appear once when queued, which means that even if they are sent multiple times, only one will be received in the end. There is also a difference in the order of taking out the queue, that is, the first signal taken out must be a real-time signal.

PS:

• kill and killall send SIGTERM signal by default.
• SIGKILL cannot be blocked or ignored under Linux.
• By default, SIGCHLD is not ignored, so you need to pay attention to this when programming (either set SIG_IGN or actively wait).
• All signals without defined processing functions will exit the process by default.
• After the signal is blocked, it still exists in the queue but is not processed. If the block is released, it will be processed.
• A signal can interrupt a process that was put to sleep by a sleep call.

1.2 Signal Status

The "pending" state of a signal refers to the period from the generation of the signal to the processing of the signal; the "blocking" of a signal is a switching action, which means preventing the signal from being processed but not preventing the signal from being generated.

For example, before sleeping, sigprocmask is used to block the exit signal, then sleep is performed, and then an exit signal is generated during the sleep process. However, at this time, the exit signal has been blocked (the Chinese word "blocking" is easily misunderstood as a state. In fact, it is an action similar to a switch, so it is said "blocked" instead of "blocked"), so it is in the "pending" state. After sleeping, sigprocmask is used to turn off the blocking switch of the exit signal. Because the exit signal generated before has been in the pending state, when the blocking switch is turned off, it immediately exits the "pending" state and is processed. All this happens before sigprocmask returns.

1.3 Signal Life Cycle

For a complete signal life cycle (from the signal being sent to the completion of the corresponding processing function), it can be divided into three important stages, which are characterized by four important events:

1. Signal is born;

2. The signal is registered in the process;

3. The signal is deregistered in the process;

4. The signal processing function is executed. The time interval between two adjacent events constitutes a stage in the signal life cycle.

The following is an explanation of the practical significance of the four events:

• The signal is "born". The birth of a signal refers to the occurrence of an event that triggers the signal (such as detecting a hardware anomaly, a timer timeout, and calling the signal sending function kill() or sigqueue(), etc.).
• The signal is "registered" in the target process; the task_struct structure of the process contains data members about pending signals in this process:

struct sigpending pending;
struct sigpending
{
    struct sigqueue *head, **tail;
    sigset_t signal;
};

Signal registration in a process means that the signal value is added to the pending signal set of the process (the second member of the sigpending structure, sigset_t signal), and the information carried by the signal is retained in a sigqueue structure in the pending signal information chain. As long as the signal is in the pending signal set of the process, it means that the process is aware of the existence of these signals but has not had time to process them, or the signal is blocked by the process.

1. The signal is deregistered in the process. During the execution of the target process, it will check whether there are any signals waiting to be processed (this check is done every time when returning from system space to user space). If there is a pending signal waiting to be processed and the signal is not blocked by the process, the process will remove the structure occupied by the signal in the pending signal chain before running the corresponding signal processing function. Whether a signal is removed from the process's pending signal set is different for real-time and non-real-time signals. For non-real-time signals, since they only occupy one sigqueue structure at most in the pending signal information chain, the signal should be deleted from the process pending signal set after the structure is released (the signal cancellation is completed); for real-time signals, they may occupy multiple sigqueue structures in the pending signal information chain, so they should be treated differently according to the number of occupied gqueue structures: if only one sigqueue structure is occupied (the process only receives the signal once), the signal should be deleted from the process's pending signal set (the signal cancellation is completed). Otherwise, the signal is not removed from the pending signal set of the process (signal cancellation is completed). Before a process executes the corresponding signal processing function, it must first deregister the signal in the process.

2. Signal life ends. After the process cancels the signal, the corresponding signal processing function is executed immediately. After the execution is completed, the influence of the signal sent this time on the process is completely ended.

1.4. Execution and cancellation of signals

The kernel handles the soft interrupt signal received by a process in the context of the process, so the process must be in the running state. When it regains the CPU due to being awakened by a signal or normal scheduling, it will detect whether there is a signal waiting to be processed when it returns from kernel space to user space. If there is a pending signal waiting to be processed and the signal is not blocked by the process, the process will remove the structure occupied by the signal in the pending signal chain before running the corresponding signal processing function. When all unmasked signals have been processed, it can return to user space. For a masked signal, when the mask is removed, the above-mentioned check and processing flow will be executed again when returning to the user space.

There are three types of signal processing: the process exits after receiving the signal; the process ignores the signal; the process executes the function set by the user using the system call signal after receiving the signal. When a process receives a signal that it ignores, the process discards the signal and continues to run as if it had not received the signal. If the process receives a signal to be caught, the user-defined function is executed when the process returns from kernel mode to user mode. Moreover, the method of executing user-defined functions is very clever. The kernel creates a new layer on the user stack, in which the value of the return address is set to the address of the user-defined processing function. In this way, when the process returns from the kernel and pops the top of the stack, it returns to the user-defined function. When it returns from the function and pops the top of the stack again, it returns to the place where it originally entered the kernel. The reason for this is that user-defined processing functions cannot and are not allowed to be executed in kernel mode (if user-defined functions are run in kernel mode, the user can obtain any permissions).

For example:

#include <assert.h>
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <signal.h>
#include <unistd.h>

void myHandler(int num)
{
    int ret = 0;
    
    if (SIGUSR1 == num)
    {
        sigset_t set;
        ret = sigemptyset(&set);
        assert(!(-1 == ret));
        ret = sigaddset(&set, SIGINT);
        assert(!(-1 == ret));
        ret = sigaddset(&set, SIGRTMIN);
        assert(!(-1 == ret));
        ret = sigprocmask(SIG_UNBLOCK, &set, NULL);
        assert(!(-1 == ret));
        printf("unblocking recv sig num: %d\n", num);
    }
    else if (num == SIGINT || num == SIGRTMIN)
    {
        printf("recv sig num: %d\n", num);
    }
    else
    {
        printf("Other signal recv sig num: %d\n", num);
    }
}

int main(void)
{
    pid_t pid;
    int ret = 0;
    //Set callback function struct sigaction act;
    act.sa_handler = myHandler;
    act.sa_flags = SA_SIGINFO;
    // Register the processing function of non-real-time signal ret = sigaction(SIGINT, &act, NULL);
    assert(!(-1 == ret));
    // Register the real-time signal processing function ret = sigaction(SIGRTMIN, &act, NULL);
    assert(!(-1 == ret));
    // Register user-defined signal ret = sigaction(SIGUSR1, &act, NULL);
    assert(!(-1 == ret));
    
    // Add SIGINT SIGRTMIN to the blocking status word sigset_t set;
    ret = sigemptyset(&set);
    assert(!(-1 == ret));
    ret = sigaddset(&set, SIGINT);
    assert(!(-1 == ret));
    ret = sigaddset(&set, SIGRTMIN);
    assert(!(-1 == ret));
    ret = sigprocmask(SIG_BLOCK, &set, NULL);
    assert(!(-1 == ret));
    
    pid = fork();
    assert(!(-1 == ret));
    if (0 == pid)
    {
        union sigval value;
        value.sival_int = 10;
        int i = 0;
        // Send three unstable signals for (i = 0; i < 3; i++)
        {
            ret = sigqueue(getppid(), SIGINT, value);
            assert(!(-1 == ret));
            printf("Sending unreliable signal ok\n");
        }
        
        //Send three stable signals value.sival_int = 20;
        for (i = 0; i < 3; i++)
        {
            ret = sigqueue(getppid(), SIGRTMIN, value);
            assert(!(-1 == ret));
            printf("send reliable signal ok\n");
        }
        //Send SIGUSR1 to the parent process to unblock ret = kill(getppid(), SIGUSR1);
        assert(!(-1 == ret));
    }
    while (1)
    {
        sleep(1);
    }
    return 0;
}

2. Inheritance of signal masks and signal processing functions

2.1. Inheritance of signal processing functions

The signal processing function is a process attribute, so the signal processing function of each thread in the process is the same. The child process created by fork will inherit the signal processing function of the parent process. After execve, the signal processing function set to be processed will be reset to the default function, and the signals set to be ignored will remain unchanged. This means that if the signal setting in the parent process is SIG_IGN, then when the child process is exec, the processing of this signal will still be ignored and will not be reset to the default function.

For example:

// test.c --> test
#include <stdlib.h>
  
typedef void (*sighandler_t)(int);
static sighandler_t old_int_handler;
  
static sighandler_t old_handlers[SIGSYS + 1];
  
void sig_handler(int signo)
{
    printf("receive signo %d\n",signo);
    old_handlers[signo](signo);
}
  
int main(int argc, char **argv)
{
    old_handlers[SIGINT] = signal(SIGINT, SIG_IGN);
    old_handlers[SIGTERM] = signal(SIGTERM, sig_handler);
  
    int ret;
  
    ret = fork();
    if (ret == 0) {
        //child
        // Here execlp will run test2 as a child process.
        execlp("/tmp/test2", "/tmp/test2",(char*)NULL);
    }else if (ret > 0) {
        //parent
        while(1) {
            sleep(1);
        }
    }else{
        perror("");
        abort();
    }
  
}
  
================================================
test2.c --> test2
#include <stdio.h>
int main(int argc, char **argv)
{
    while(1) {
        sleep(1);
    }
    return 0;
}

Conclusion: After test is changed to test2, SIGINT is still ignored and SIGTERM is reset to the default mode.

2.2 Signal Mask Inheritance

The signal mask has the following rules:

1. Each thread can have its own signal mask.

2. The forked child process will inherit the signal mask of the parent process, and the signal mask remains unchanged after exec. If the parent process is multithreaded, then the child process only inherits the mask of the main thread.

3. The signal sent to the process will be received by any thread that does not block the signal. Note that only one thread will receive it randomly. In Linux, if all threads can receive signals, the signal will be sent to the main thread by default, while in POSIX system it is sent randomly.

4. After fork, the pending signal set in the child process is initialized to empty, and exec will keep the pending signal set.

#include <stdio.h>
#include <signal.h>
#include <unistd.h>
#include <stdlib.h>
#include <pthread.h>
  
typedef void (*sighandler_t)(int);
  
static void *thread1(void *arg)
{
    sigset_t set;
      
    printf("in thread1\n");
  
    sigemptyset(&set);
    sigaddset(&set, SIGTERM);
    pthread_sigmask(SIG_BLOCK, &set, NULL);

    while(1) {
        sleep(1);
    }
}
  
static void sigset_print(sigset_t *set)
{
    int i;
  
    for (i = 1; i <= SIGSYS; i++) {
        if (sigismember(set, i)) {
            printf("signal %d is in set\n",i);
        }
    }
}
  
int main(int argc, char **argv)
{
    int ret;
    sigset_t set;
    pthread_t pid;
  
    pthread_create(&pid, NULL, thread1, NULL);
    sleep(1);
  
    sigemptyset(&set);
    sigaddset(&set, SIGINT);
    pthread_sigmask(SIG_BLOCK, &set, NULL);
  
    ret = fork();
    if (ret == 0) {
        //child
        pthread_sigmask(SIG_BLOCK, NULL, &set);
        sigset_print(&set);
  
        while(1) {
            sleep(1);
        }
    }else if (ret > 0) {
        //parent
        while(1) {
            sleep(1);
        }
    }else{
        perror("");
        abort();
    }
  
}

Conclusion: Only the mask set in the main thread is inherited by the child process. The reason for this is that fork in Linux only copies the thread that calls fork(), so in the child process only the main thread of the parent process is copied, and of course the signal mask is a copy of the signal mask of the main thread of the parent process. This proves again that if fork is called in thread1, the signal mask of the child process will be a copy of thread1.

2.3, sigwait and multithreading

Sigwait function: sigwait waits for one or more specified signals to occur.

It only does two things:

First, listen for blocked signals;

Second, if the monitored signal is generated, it is removed from the pending queue. sigwait does not change the blocking or non-blocking state of the signal mask.

In the POSIX standard, when a process receives a signal, if it is a multi-threaded situation, we cannot determine which thread handles the signal. Sigwait takes the specified signal from the pending signals in the process. In this case, if you want to ensure that the sigwait thread receives the signal, then all threads including the main thread and the sigwait thread must block the signal, because if you do not block yourself, there will be no pending state (blocked state) signal. If all other threads do not block, it is possible that when the signal comes, it will be processed by other threads.

PS:

In multithreaded code, always use functions such as sigwait or sigwaitinfo or sigtimedwait to handle signals. Instead of functions such as signal or sigaction. Because calling functions such as signal or sigaction in a thread will change the signal processing functions in all threads, rather than just changing the signal processing function of the thread that calls signal/sigaction.

2.4. Signals in multiple processes

In multi-process mode, keyboard-triggered signals are sent to all processes in the current process group at the same time. If a program forks multiple child processes during execution, the signal triggered by the key will be received by all processes of the program.

However, unlike multi-threading, the signal masks and signal processing functions under multi-process are independent. Each process can choose to handle or not handle, and can also set its own signal mask.

#include <stdio.h>
#include <sys/types.h>
#include <unistd.h>
#include <signal.h>

int main(int argc, char **argv)
{
    pid_t pid = fork();

    signal(SIGCHLD, SIG_IGN);
    if (pid < 0)
        printf("error fork\n");
    else if (pid == 0)
    {
        signal(SIGINT, SIG_IGN); // Ignore SIGINT so that the child process can survive after ctrl+c; if not set, it will exit when receiving the signal printf("child gid = %ld\n", getpgid(getpid()));
        do
        {
            sleep(1);
        } while (1);
    }
    else
    {
        printf("parent gid = %ld\n", getpgid(getpid()));
        do
        {
            sleep(1);
        } while (1);
    }

    return 0;
} 

As shown in the figure above, you can see that the parent process exits after receiving SIGINT, and the child process is not affected because it is set to ignore SIGINT.

APIs

3.1 Signal generation function

1.kill(pid_t pid, int signum);

2. int sigqueue(pid_t pid, int sig, const union sigval value);

3.pthread_kill(pthread_t tid, int signum);

4.raise(int signum); // Send a signal to yourself

5.void alarm(void);

6.void abort(void);

7.int setitimer(int which, const struct itimerval *new_value, struct itimerval *old_value);

PS:

sigqueue() passes more additional information than kill(), but sigqueue() can only send signals to a process, not to a process group. If signo=0, error checking will be performed, but no signal will actually be sent. The 0-value signal can be used to check the validity of pid and whether the current process has permission to send signals to the target process.

3.2 Signal processing function

1.signal(int signum, void (*handler)(int signum))

2.sigaction(int signum, struct sigaction* newact, sigaction* oldact)

sigaction act;
act.sa_handler = handler;
act.sa_flags = SA_SIGINFO;
// Register signal processing function sigaction(SIGINT, act, NULL);

3.3 Signal mask function

1.sigprocmask(int how, struct sigaction* set,struct sigaction* oldset)

2.pthread_sigmask(int how, struct sigaction* set,struct sigaction* oldset)

sigprocmask is used to set the signal mask of the process, and pthread_sigmask is used to set the signal mask of the thread. The parameters of the two are the same. The first parameter has SIG_BLOCK, SIG_UNBLOCK, SIG_SETMASK .

3.4. Signal Collection Variables

sigset_t set

sigemptyset(&set) // Clear the blocking signal set variable

sigfillset(&set) //Add all signals to the blocking set variable

sigaddset(&set,SIGINT) //Add a single signal to the blocked signal set variable

sigdelset(&set,SIGINT) //Delete a single signal from the blocked signal set variable

sigismember(&set, int signum) //Test whether the signal signum is contained in the signal set set. If it is contained, it returns 1, if not, it returns 0, and if an error occurs, it returns -1. There is only one error code, EINVAL, which means that signum is not a valid signal code.

3.5. Signal shielding function

1.int sigpending(sigset_t *set); // Returns the blocked signal set

2.int sigsuspend(const sigset_t *mask);

sigsuspend means temporarily setting the signal mask to mask and suspending the process until a signal is generated (unmasked signals can wake up or terminate the process). If the signal processing function returns, siguspend will restore the previous signal mask (temporarily)

Assume that signal A is generated when sisuspend blocks the process, and A is not a masked signal in mask, then there are two situations for the signal processing function of A.

1: Terminate the process directly. At this time, the process no longer exists, so sigsuspend does not need to return (if there is no process, sigsuspend does not exist either, as does the function stack);

2. If the processing function of signal A returns, the signal mask word is restored to the state before sigsuspend (the signal mask word is set to mask when sigsuspend is called, so it must be restored to the state before sigsuspend is called), and then sigsuspend returns -1 and sets error to EINTR.

The above is a brief discussion of the details of the Linux signal mechanism. For more information about the Linux signal mechanism, please pay attention to other related articles on 123WORDPRESS.COM!