List of Kill Signals [duplicate]
1 Answer 1
man 7 signal will show you a complete table with a brief summary of the meaning of each signal:
First the signals described in the original POSIX.1-1990 standard. 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 terminal SIGTTIN 21,21,26 Stop Terminal input for background process SIGTTOU 22,22,27 Stop Terminal output for background process The signals SIGKILL and SIGSTOP cannot be caught, blocked, or ignored. Next the signals not in the POSIX.1-1990 standard but described in SUSv2 and POSIX.1-2001. 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,31,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) Up to and including Linux 2.2, the default behavior for SIGSYS, SIGX‐ CPU, SIGXFSZ, and (on architectures other than SPARC and MIPS) SIGBUS was to terminate the process (without a core dump). (On some other UNIX systems the default action for SIGXCPU and SIGXFSZ is to terminate the process without a core dump.) Linux 2.4 conforms to the POSIX.1-2001 requirements for these signals, terminating the process with a core dump. Next various other signals. 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 (unused) SIGWINCH 28,28,20 Ign Window resize signal (4.3BSD, Sun) SIGUNUSED -,31,- Core Synonymous with SIGSYS (Signal 29 is SIGINFO / SIGPWR on an alpha but SIGLOST on a sparc.) SIGEMT is not specified in POSIX.1-2001, but nevertheless appears on most other UNIX systems, where its default action is typically to ter‐ minate the process with a core dump. SIGPWR (which is not specified in POSIX.1-2001) is typically ignored by default on those other UNIX systems where it appears. SIGIO (which is not specified in POSIX.1-2001) is ignored by default on several other UNIX systems. Where defined, SIGUNUSED is synonymous with SIGSYS on most architec‐ tures. Linux kill signal numbers
This tutorial explains what Linux kill signals are and how to use them to interrupt, terminate, suspend and continue processes.
What is Linux kill signals?
Kill signals allow interaction between different processes. Concretely signals are event notifications sent to processes mostly to interrupt, terminate, kill or suspend processes (That’s why we use the term “kill”). Signals can be sent by processes or by the kernel, and normally they are sent when an anomaly or exceptional condition requires special processing, or when a user interrupts or terminates a process manually (e.g., when pressing Ctrl+C),
When a signal is sent to a process, that signal, or notification, may meet a default action as a response or may be handled by a signal handler. A signal handler is a custom code of the program whose process received the signal, which defines the behavior of the process when the signal is received (except for signals SIGKILL and SIGSTOP, which can’t be handled, ignored, nor blocked).
When the signal is sent, the default actions which may take place are the following:
- Term: The process is terminated.
- Ign: The signal is ignored without affecting the process.
- Core: A dump-core file is created.
- Stop: The process is stopped.
- Cont: The process resumes after being stopped.
Depending on the signal some of these actions may take place, the program also can contain a signal handler to execute the proper action.
Summarized: signals are messages delivered to processes notifying them an event occurred.
Available signals:
To list all signal names and numbers on your system, you can use the kill command followed by the -l flag, as shown below.
As you can see, there are 64 signals, probably the most known by all of us is the number 9 (SIGKILL) used to terminate processes including child processes, immediately.
- SIGKILL (9): The SIGKILL signal is used to kill or terminate processes immediately. SIGKILL signals can’t be handled, ignored, or stopped.
- SIGSTOP (19): This signal is to stop or pause processes that can be later resumed.
- SIGCONT (18): The SIGCONT signal is used to resume stopped or paused processes.
How to use kill signals:
The correct syntax to send signals is:
You can replace ir with the names or numbers we got previously when running the kill -l command. The PID is the process ID you can learn by using the ps command as shown in the following instructions.
To begin the practical section of this tutorial, let’s try the SIGSTOP and SIGCONT to pause a process and then resume it.
For the first example, I created a little code-named linuxhintsignal that continuously prints “linuxhint.com” as shown in the screenshot below.
To send a signal to the process, before I need to learn its PID. To see the Process ID (PID) you need to run the ps command. In my case, I’m the one who executed the process, so I use the ps command followed by the -u flag to show my processes only.
Note: for more instructions on the ps command, read Using the ps command in Linux.
As you can see, the PID of the running linuxhintsignal script is 16182.
The following screenshot shows two terminals; the right terminal shows the delivery of the SIGSTOP signal to process 16182. The left terminal shows how the process is stopped when I send the signal.
As you can see on the right terminal, the process was stopped properly.
You need to send the SIGCONT signal to resume the process execution, as shown in the screenshots below.
As you can see, the process resumed.
You can achieve the same result by replacing the signal names for their numbers. The following example repeats the previous scenario, but this time is defining signals by their numbers.
The following example also shows how the SIGKILL is delivered to process 17721 to pause it. This time instead of specifying the signal name, I specify the signal number returned by the kill -l command, in this case, 19 for the SIGSTOP signal.
The following screenshot shows how to specify the SIGCONT signal, also using its number instead of its name.
As you can see, the result is the same when using the signal name or number.
As said previously, the SIGKILL signal is used to terminate a process fully; it is probably the most used signal by users.
As you can see in the example below, in which SIGKILL is implemented with its number (9), the script was fully terminated or killed.
Other important signals:
- SIGINT: This signal is delivered when the user requests the process interruption (e.g., Ctrl+C).
- IGTERM: The SIGTERM signal is delivered to request a process termination, but only to request and not to terminate. Contrary to SIGKILL or SIGSTOP, this signal can be handled, blocked, or ignored.
- SIGILL: This signal is used to terminate processes as the cause of an error such as operation or execution errors. This signal can’t be ignored.
- SIGCHLD: Used to notify parent processes on child processes events.
- SIGHUP: This signal is triggered when the connection is abruptly interrupted.
- SIGPIPE: This signal is sent to processes trying to write to a pipe without a read end or which can’t be read.
- SIGQUIT: This signal is similar to SIGINT but produces a core dump.
Conclusion:
Using Linux signals to kill, stop, pause processes, among other functions, is a basic knowledge any Linux user must hold. Deep knowledge of signals is especially relevant for programmers who must ensure that signal handlers don’t produce unwanted effects on the system. As you can see, there are dozens of available signals; this tutorial only focused on the most common ones. You can get more information on Linux signals at https://www.gnu.org/software/libc/manual/html_node/Standard-Signals.html.
Thank you for reading Linux Hint; keep following us for more Linux tips and tutorials.
About the author
David Adams
David Adams is a System Admin and writer that is focused on open source technologies, security software, and computer systems.