signal — Linux/Unix Command

Send signals to your programs, and control how they run

Linux supports both POSIX reliable signals (hereinafter, "standard signals") and POSIX real-time signals.

Using Signals on Linux

Signals on a Linux system tell the operating system how to handle a running program or process. When you close a program normally, that actually sends a signal to the system telling it to close the program. You can do this manually too.

Start by looking for a process that you want to shut down. You can do this with:

ps aux | grep -i <program name>

So, if you want to close Firefox from the command line, enter:

ps aux | grep -i firefox

You'll get a huge list of processes from Firefox, because it's a multithreaded application. Look for the base process for /usr/lib/firefox. It's usually the first one.

Linux process list Firefox

If you find that overwhelming, you can also use pgrep. It works similarly but only gives you the process IDs.

pgrep firefox

The lowest process ID will be the base process that you need.

Linux pgrep Firefox

When you have it, find the process ID number. The first thing listed will always be the user running the process. Next will be the process ID. With that in hand, you can send a SIGTERM signal to the process to stop it using the kill command.

kill -SIGTERM 4790
Linux SIGTERM Firefox

Each signal also has a corresponding number for shorthand. The number for SIGTERM is 15, so you can use that just the same as the full word.

kill -15 4790

SIGTERM is actually the default action of the kill command. As a result, you actually don't need to specify it at all. Just use:

kill 4790

You'll get the exact same result.

That's all well and good if the process is responsive, but you probably won't shut down a responsive process this way, at least not on a desktop. So, what do you do with an unresponsive process? There are a ton of possible signals. For a better idea of just how wide the range is, look them up.

kill -l
Linux signal list

Yeah, there are a lot. Thankfully, you won't touch the vast majority, unless you start developing or writing system administration scripts. More often than not, when SIGTERM fails to stop an unresponsive process, you're going to look to the Linux equivalent of CTRL+Alt+Delete, SIGKILL.

Unlike the infamous CTRL+ALT+Delete process manager, SIGKILL actually works. In fact, it's meant to ignore all other factors and take down the offending process, no matter what. That also means that SIGKILL can be dangerous if you get the process wrong.

Start out the exact same way, by looking up the process ID.

pgrep firefox

Now, instead of using SIGTERM to stop the process, employ the more destructive SIGKILL.

kill -SIGKILL 4790

Even if the process is completely locked up, it should close within a few seconds.

Linux SIGKILL Firefox

Just like with SIGTERM, there's a number corresponding to SIGKILL. In this case, it's 9.

kill -9 4790

Just like before, the process should be dead almost immediately.

You should also be aware of SIGINT. This is an interrupt from the keyboard, and it's more command than you think in the command line. When you press CTRL+C to stop a process from a terminal window, you're actually issuing a SIGINT. Its code is 2, and you can use it just like the others with the kill command.

kill -2 4790

This isn't all too common since you're much more likely to go with CTRL+C, but it's good to be aware of it.

These are by far the most common signals that you'll encounter in your daily Linux use. For a more technical breakdown of the other signals, continue on to the next section.

The Technical Details

If you're a system administrator or looking to develop for Linux, you probably want to dive deeper into the technical details behind the signal system on Linux. The next section explores the full technical breakdown of Linux signals. You absolutely don't need this information to use Linux on your desktop, but if you intend to explore the inner workings of the system, it can prove invaluable.

Standard Signals

Linux supports the standard signals listed below. Several signal numbers are architecture-dependent, as indicated in the "Value" column. (Where three values are given, the first one is usually valid for alpha and sparc, the middle one for i386, ppc and sh, and the last one for mips. A - denotes that a signal is absent on the corresponding architecture.)

The entries in the "Action" column of the table specify the default action for the signal, as follows:

Term: Default action is to terminate the process.

Ign: Default action is to ignore the signal.

Core: Default action is to terminate the process and dump core.

Stop: Default action is to stop the process.

First, the signals described in the original POSIX.1 standard.

Signal Value Action Comment
      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   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

The signals SIGKILL and SIGSTOP cannot be caught, blocked, or ignored.

Next the signals not in the POSIX.1 standard but described in SUSv2 and SUSv3 / POSIX 1003.1-2001.

Signal Value Action Comment
SIGPOLL   Term Pollable event (Sys V). Synonym of SIGIO
SIGPROF 27,27,29 Term Profiling timer expired
SIGSYS 12,-,12 Core Bad argument to routine (SVID)
SIGTRAP 5 Core Trace/breakpoint trap
SIGURG 16,23,21 Ign Urgent condition on socket (4.2 BSD)
SIGVTALRM 26,26,28 Term Virtual alarm clock (4.2 BSD)
SIGXCPU 24,24,30 Core CPU time limit exceeded (4.2 BSD)
SIGXFSZ 25,25,31 Core File size limit exceeded (4.2 BSD)

Up to and including Linux 2.2, the default behavior for SIGSYSSIGXCPUSIGXFSZ, and (on architectures other than SPARC and MIPS) SIGBUS was to terminate the process (without a core dump). (On some other Unices the default action for SIGXCPU and SIGXFSZ is to terminate the process without a core dump.) Linux 2.4 conforms to the POSIX 1003.1-2001 requirements for these signals, terminating the process with a core dump.

Next, various other signals.

Signal Value Action Comment
SIGEMT 7,-,7 Term  
SIGSTKFLT -,16,- Term Stack fault on coprocessor (unused)
SIGIO 23,29,22 Term I/O now possible (4.2 BSD)
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.3 BSD, Sun)
SIGUNUSED -,31,- Term Unused signal (will be SIGSYS)

(Signal 29 is SIGINFO / SIGPWR on an alpha but SIGLOST on a sparc.)

SIGEMT is not specified in POSIX 1003.1-2001, but nevertheless appears on most other Unices, where its default action is typically to terminate the process with a core dump.

SIGPWR (which is not specified in POSIX 1003.1-2001) is typically ignored by default on those other Unices where it appears.

SIGIO (which is not specified in POSIX 1003.1-2001) is ignored by default on several other Unices.

Real-Time Signals

Linux supports real-time signals as originally defined in the POSIX.4 real-time extensions (and now included in POSIX 1003.1-2001). Linux supports 32 real-time signals, numbered from 32 (SIGRTMIN) to 63 (SIGRTMAX). (Programs should always refer to real-time signals using notation SIGRTMIN+n, since the range of real-time signal numbers varies across Unices.)

Unlike standard signals, real-time signals have no predefined meanings: the entire set of real-time signals can be used for application-defined purposes. (Note, however, that the LinuxThreads implementation uses the first three real-time signals.)

The default action for an unhandled real-time signal is to terminate the receiving process.

Real-time signals are distinguished by the following:

  1. Multiple instances of real-time signals can be queued. By contrast, if multiple instances of a standard signal are delivered while that signal is currently blocked, then only one instance is queued.
  2. If the signal is sent using sigqueue(2), an accompanying value (either an integer or a pointer) can be sent with the signal. If the receiving process establishes a handler for this signal using the SA_SIGACTION flag to sigaction(2) then it can obtain this data via thesi_value field of the siginfo_t structure passed as the second argument to the handler. Furthermore, the si_pid and si_uid fields of this structure can be used to obtain the PID and real user ID of the process sending the signal.
  3. Real-time signals are delivered in a guaranteed order. Multiple real-time signals of the same type are delivered in the order they were sent. If different real-time signals are sent to a process, they are delivered starting with the lowest-numbered signal. (I.e., low-numbered signals have highest priority.)

If both standard and real-time signals are pending for a process, POSIX leaves it unspecified which is delivered first. Linux, like many other implementations, gives priority to standard signals in this case.

According to POSIX, an implementation should permit at least _POSIX_SIGQUEUE_MAX (32) real-time signals to be queued to a process. However, rather than placing a per-process limit, Linux imposes a system-wide limit on the number of queued real-time signals for all processes. This limit can be viewed (and with privilege) changed via the /proc/sys/kernel/rtsig-max file. A related file,/proc/sys/kernel/rtsig-max, can be used to find out how many real-time signals are currently queued.



Use the man command (% man) to see how a command is used on your particular computer.