Signal types in Linux systems
The signal definitions of each operating system may be somewhat different. The signals defined in POSIX are listed below.
Use 34-64 signals in linux as a real-time system.
Command man 7 signal provides an official signal introduction. You can also use kill -l to quickly view it
In the list, the signals numbered 1 to 31 are signals supported by traditional UNIX, which are unreliable signals (non-real-time), and the signals numbered 32 to 63 were later expanded and are called reliable signals (real-time signals). The difference between an unreliable signal and a reliable signal is that the former does not support queueing, which may cause signal loss, while the latter does not.
The following are the standard signals supported by Linux. One signal has multiple values because different architectures use different values. For example, x86, ia64, ppc, s390, there are 3 values. The first value is slpha and sparc. The middle value is ix86, ia64, ppc, s390, arm and sh. The last value is for mips. The hyphen means that this architecture lacks support for this signal.
Column 1 is the signal name;
The second column is the corresponding signal value. It should be noted that some signal names correspond to 3 signal values. This is because these signal values are related to the platform. The description of the 3 signal values in the manuscript is extracted as follows. The first one is usually valid for alpha and sparc, the middle one for i386, ppc and sh, and the last one for mips.
Column 3 shows the action after the operating system receives a signal. Term indicates that the default action is to terminate the process. Ign indicates that the default action is to ignore the signal. Core indicates that the default action is to terminate the process and outputs core dump. Stop indicates that the default action is to stop the process.
Column 4 is an annotational description of the effect of the signal.
Standard Signal-POSIX.1-1990 Definition
Signal Value Action Comment
----------------------------------------------------------------------
SIGHUP 1 Term Hangup detected on controlling terminal
or death of controlling process
SIGINT 2 Term Interrupt from keyboard
SIGQUIT 3 Core Quit from keyboard
SIGILL 4 Core Illegal Instruction
SIGABRT 6 Core Abort signal from abort(3)
SIGFPE 8 Core Floating point exception
SIGKILL 9 Term Kill signal
SIGSEGV 11 Core Invalid memory reference
SIGPIPE 13 Term Broken pipe: write to pipe with no
readers
SIGALRM 14 Term Timer signal from alarm(2)
SIGTERM 15 Term Termination signal
SIGUSR1 30,10,16 Term User-defined signal 1
SIGUSR2 31,12,17 Term User-defined signal 2
SIGCHLD 20,17,18 Ign Child stopped or terminated
SIGCONT 19,18,25 Cont Continue if stopped
SIGSTOP 17,19,23 Stop Stop process
SIGTSTP 18,20,24 Stop Stop typed at tty
SIGTTIN 21,21,26 Stop tty input for background process
SIGTTOU 22,22,27 Stop tty output for background process
SIGKILL and SIGSTOP signals cannot be captured, blocked and ignored.
Standard Signal-SUSv2 and POSIX.1-2001 Definition
Signal Value Action Comment
--------------------------------------------------------------------
SIGBUS 10,7,10 Core Bus error (bad memory access)
SIGPOLL Term Pollable event (Sys V).
Synonym for SIGIO
SIGPROF 27,27,29 Term Profiling timer expired
SIGSYS 12,-,12 Core Bad argument to routine (SVr4)
SIGTRAP 5 Core Trace/breakpoint trap
SIGURG 16,23,21 Ign Urgent condition on socket (4.2BSD)
SIGVTALRM 26,26,28 Term Virtual alarm clock (4.2BSD)
SIGXCPU 24,24,30 Core CPU time limit exceeded (4.2BSD)
SIGXFSZ 25,25,31 Core File size limit exceeded (4.2BSD)
As early as Linux 2.2, the default operation of SIGSYS, SIGXCPU, SIGXFSZ and SIGBUS (non-sparc and mips architectures) is to terminate the process (but no coredump is generated)
In some Unix systems, SIGXCPU and SIGXFSZ signals are used to terminate the process and do not generate coredunp. Starting from Linux 2.4, these signals will generate coredump.
Standard Signal-Other Signal
Signal Value Action Comment -------------------------------------------------------------------- SIGIOT 6 Core IOT trap. A synonym for SIGABRT SIGEMT 7,-,7 Term SIGSTKFLT -,16,- Term Stack fault on coprocessor (unused) SIGIO 23,29,22 Term I/O now possible (4.2BSD) SIGCLD -,-,18 Ign A synonym for SIGCHLD SIGPWR 29,30,19 Term Power failure (System V) SIGINFO 29,-,- A synonym for SIGPWR SIGLOST -,-,- Term File lock lost SIGWINCH 28,28,20 Ign Window resize signal (4.3BSD, Sun) SIGUNUSED -,31,- Term Unused signal (will be SIGSYS)
Signal 29 is SIGINFO or SIGPWR in alpha, but SIGLOST in sparc.
SIGEMT is not defined in POSIX.1-2001, but it is not available in most Unix dramas. Its default handling method is coredump and terminates the process.
SIGPWR (not defined in POSIX.1-2001) His default handling method is to ignore.
SIGIO (not defined in POSIX.1-2001) is also ignored in some Unix systems.
The kill pid function is to send SIGTERM to a process with process number pid (this is the signal sent by kill by default), which is a signal that ends the process and can be captured by the application. If the application does not have the logic code to capture and respond to the signal, the default action of the signal is to kill the process. This is a recommended practice for terminating a specified process.
kill -9 pid sends SIGKILL to a process with process number pid (the signal is numbered 9). From the above description in this article, it can be seen that SIGKILL cannot be captured by the application, nor can it be blocked or ignored. Its action is to end the specified process immediately. In layman's terms, the application cannot "sensitize" the SIGKILL signal at all. It is killed by the operating system that receives the SIGKILL signal when it is completely unprepared. Obviously, in this "violent" situation, the application has no chance to release the current resource occupancy at all. In fact, the SIGKILL signal is sent directly to the init process. After receiving the signal, it is responsible for terminating the process specified by the pid. In some cases (if the process has died and cannot respond to normal signals), you can use kill -9 to end the process.
If the process ended through kill is a parent process that has created a child process, its child process will become an Orphan Process. In this case, the exit status of the child process can no longer be captured by the application process (because the application as the parent process no longer exists), but it should not have any adverse impact on the entire Linux system.
Signal transmission and processing in Go
Sometimes we want to process Signal signals in Go programs, such as elegantly closing the program after receiving the SIGTERM signal (see the application in the next section). Go signaling mechanism can be sent to a channelaccomplish. First we create a channel, then useRegister the signal to be received.
package main
import (
"fmt"
"os"
"os/signal"
"syscall"
)
func main() {
sigs := make(chan , 1)
done := make(chan bool, 1)
// (c)
(sigs, , , syscall.SIGUSR1, syscall.SIGUSR2, , )
go func() {
sig := <-sigs
(sig)
done <- true
}()
("wait for signal")
<- done
("got signal and exit")
("run done")
}
How to implement elegant exit of a process
First of all, what is elegant exit? The so-called elegant exit is actually to avoid violently killing the process, so that the process will automatically do some after-care after receiving the signal, and then voluntarily exit.
Applications on the Linux Server side often run for a long time. During the operation, they may apply for a lot of system resources or save a lot of states. In these scenarios, we hope that the process can release resources or dump the current state to disk or print some important logs before exiting, that is, we hope that the process can exit gracefully.
From the above introduction, it is not difficult to see that elegant exit can be achieved by capturing SIGTERM. Specifically, only two steps are required:
1) Register the processing function of the SIGTERM signal and prepare some process exit in the processing function. Signal processing function registration can be passedsignal()orsigaction()To implement it, the latter is recommended to implement the setting of the signal response function. The simpler the logic of the signal processing function, the better. The usual practice is to set a bool-type flag variable in the function to indicate that the process has received the SIGTERM signal and is ready to exit.
2) In the main processmain()In, by similarwhile(!bQuit)The logic of , to detect the flag variable, once bQuit is set to true in the signal handler function, the main process exits the while() loop, and the next is some actions to release the resource or dump the current state of the process or record the log. After these are completed, the main process exits.
This was also introduced in my previous article [=[golang's httpserver elegantly restart][1]]https:///article/, it introduces how to restart httpserver we generally use, and also introduces some signals and ideas for elegant restart. Today we are introducing how to exit gracefully, which is actually a simplified version of elegant restart.
package main
import (
"fmt"
"os"
"os/signal"
"syscall"
"time"
)
func main() {
sigs := make(chan , 1)
// done := make(chan bool, 1)
// (sigs)
// (sigs, , , syscall.SIGUSR1, syscall.SIGUSR2, , )
(sigs, syscall.SIGUSR1, syscall.SIGUSR2, , , , )
// go func() {
// sig := <-sigs
// (sig)
// done <- true
// }()
go func() {
for s := range sigs {
switch s {
case , , , :
("got signal and try to exit: ", s)
do_exit()
case syscall.SIGUSR1:
("usr1: ", s)
case syscall.SIGUSR2:
("usr2: ", s)
default:
("other: ", s)
}
}
}()
("wait for signal")
i := 0
for {
i++
("times: ", i)
(1 * )
}
// <- done
("got signal and exit")
("run done")
}
func do_exit() {
("try do some clear jobs")
("run done")
(0)
}
kill -USR1 pid usr1 user defined signal 1 kill -USR2 pid usr2 user defined signal 2 kill -QUIT pid got signal and try to exit: quit try do some clear jobs run done
Summarize
The above is the entire content of this article. I hope that the content of this article has certain reference value for everyone's study or work. If you have any questions, you can leave a message to communicate. Thank you for your support.