Shulou(Shulou.com)06/01 Report--

This article introduces the relevant knowledge of "signal types in Linux system and signal transmission and processing in Go". In the operation of actual cases, many people will encounter such a dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

Signal types in Linux system

The definition of signals may vary from operating system to operating system. The signals defined in POSIX are listed below.

34-64 signals are used in linux as real-time systems.

The command man 7 signal provides an official signal introduction. You can also use kill-l to quickly view

In the list, the signal numbered 1-31 is supported by traditional UNIX and is unreliable (non-real-time), while the signal numbered 32-63 is later expanded and called reliable signal (real-time signal). The difference between an unreliable signal and a reliable signal is that the former does not support queuing, which may cause signal loss, while the latter does not.

Linux supports the following standard signals. A signal has multiple values because different architectures use different values, such as x86, ia64,ppc, and s390. There are three values. The first value is slpha and sparc, and the middle value is ix86.

Ia64, ppc, S390, arm and sh, the last value is for mips, hyphen-indicates that the architecture lacks this signal support

List 1 as the signal name

The second column is the corresponding signal value, it should be noted that some signal names correspond to three signal values, this is because these signal values are related to the platform, the description of the three signal values in the man manual 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.

The third is the action after the operating system receives the signal. Term indicates that the default action is as the termination process, Ign indicates that the default action is to ignore the signal, and Core indicates the default action as the termination process and outputs core dump,Stop as the default action as the stop process.

The fourth is an annotative description of the signal function.

Standard signal-POSIX.1-1990 defines 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 Ign Child stopped 10 Term User-defined signal 1 SIGUSR2 31 Japanese 12 Term User-defined signal 2 SIGCHLD 20 Ign Child stopped 17 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 or ignored.

Standard signal-SUSv2 and POSIX.1-2001 Definitions Signal Value Action Comment-SIGBUS 10pr 7 10 Core Bus error (bad memory access) SIGPOLL Term Pollable event (Sys V). Synonym for SIGIO SIGPROF 27 SVr4 27 Term Profiling timer expired SIGSYS 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)

Back in Linux 2.2SIGSYS, SIGXCPU, SIGXFSZ, and SIGBUS (non-sparc and mips architectures), the default action was to terminate the process (but did not generate coredump)

In some unix systems, SIGXCPU and SIGXFSZ signals are used to terminate processes and do not generate coredunp. Since Linux 2.4, these signals have generated coredump.

Standard signal-other signals Signal Value Action Comment-SIGIOT 6 Core IOT trap. A synonym for SIGABRT SIGEMT 7 System System 7 Term SIGSTKFLT -, 16 Term Power failure-Term Stack fault on coprocessor (unused) SIGIO 23 SIGCLD -, 18 Ign A synonym for SIGCHLD SIGPWR 29 Ign A synonym for SIGCHLD SIGPWR 29 Term Power failure (System V) SIGINFO 29 Term Power failure-A synonym for SIGPWR SIGLOST -,- -Term File lock lost SIGWINCH 28, 28, Sun, 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 not in most Unix plays. Its default handling is coredump and terminates the process.

SIGPWR (not defined in POSIX.1-2001) his default handling is ignore.

The way SIGIO (not defined in POSIX.1-2001) is handled in some Unix systems is also ignored.

The role of kill pid is to send SIGTERM to the process with the process number pid (which is the default signal sent by kill), which is a signal to end the process and can be captured by the application. If the application does not have the logic code that captures and responds to the signal, the default action of the signal is to kill the process. This is the recommended practice for terminating a specified process.

Kill-9 pid sends SIGKILL to the process with the process number pid (the signal number is 9). As can be seen from the instructions above in this article, SIGKILL can neither be captured by the application nor blocked or ignored. Its action is to end the specified process immediately. Generally speaking, the application cannot "perceive" the SIGKILL signal at all, and it is killed by the operating system that received the SIGKILL signal completely unprepared. obviously, in this "violent" situation, the application has no chance to release the current occupation of resources. In fact, the SIGKILL signal is sent directly to the init process, and when it receives the signal, it is responsible for terminating the process specified by pid. In some cases (such as when the process is hang dead and unable to respond to normal signals), you can use kill-9 to end the process.

If the process that ends through kill is a parent process that has created a child process, the child process will become an orphan process (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 the Signal signal in the Go program, such as gracefully shutting down the program after receiving the SIGTERM signal (see the application in the next section). The Go signal notification mechanism can be implemented by sending an os.Signal to a channel. First we create an os.Signal channel, and then use signal.Notify to register the signal to be received.

Package mainimport ("fmt"os"os/signal"syscall") func main () {sigs: = make (chan os.Signal, 1) done: = make (chan bool, 1) / / signal.Notify (c) signal.Notify (sigs, os.Interrupt, os.Kill, syscall.SIGUSR1, syscall.SIGUSR2, syscall.SIGINT Syscall.SIGTERM) go func () {sig: =

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.