Linux KiLL command

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.)

First the signals described in the original POSIX.1-1990 standard.

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

Thus, if it is desired to terminate a process with a PID of 485, the following will usually be sufficient:

kill 485

The kill command has a misleading name because it does not actually kill processes. Rather, it sends signals to them. Each process is supplied with a set of standard signal handlers by the operating system in order to deal with incoming signals. When no signal is explicitly included in the command, signal 15, named SIGTERM, is sent by default. If this fails, the stronger signal 9, called SIGKILL, should be used. For example, the following command would nearly guarantee that process 485 would be killed:

kill -9 485

The only situation in which signal 9 will fail is if the process is in the midst of making a system call, which is a request to the kernel (i.e., the core of the operating system) for some action such as process creation. In this situation, the process will die once it has returned from the system call.

There are more than 60 signals that can be used with kill, but, fortunately, most users will only need to be aware of signal 9. The full list is contained in the file /usr/include/linux/signal.h and can be viewed by using kill with its -l option, i.e.,

kill -l




SIGTERM vs. SIGKILL


Sending signals to processes using kill on a Unix system is not a new topic for most systems administrators, but I've been asked many times about the difference between kill and kill -9.

Anytime you use kill on a process, you're actually sending the process a signal (in almost all situations - I'll get into that soon). Standard C applications have a header file that contains the steps that the process should follow if it receives a particular signal. You can get an entire list of the available signals on your system by checking the man page for kill.

Consider a command like this:

kill 2563

This would send a signal called SIGTERM to the process. Once the process receives the notice, a few different things can happen:

* the process may stop immediately
* the process may stop after a short delay after cleaning up resources
* the process may keep running indefinitely

The application can determine what it wants to do once a SIGTERM is received. While most applications will clean up their resources and stop, some may not. An application may be configured to do something completely different when a SIGTERM is received. Also, if the application is in a bad state, such as waiting for disk I/O, it may not be able to act on the signal that was sent.

Most system administrators will usually resort to the more abrupt signal when an application doesn't respond to a SIGTERM:

kill -9 2563

The -9 tells the kill command that you want to send signal #9, which is called SIGKILL. With a name like that, it's obvious that this signal carries a little more weight.

Although SIGKILL is defined in the same signal header file as SIGTERM, it cannot be ignored by the process. In fact, the process isn't even made aware of the SIGKILL signal since the signal goes straight to the kernel init. At that point, init will stop the process. The process never gets the opportunity to catch the signal and act on it.

However, the kernel may not be able to successfully kill the process in some situations. If the process is waiting for network or disk I/O, the kernel won't be able to stop it. Zombie processes and processes caught in an uninterruptible sleep cannot be stopped by the kernel, either. A reboot is required to clear those processes from the system.


Signal	Description	Signal number on Linux x86[1]
SIGABRT	Process aborted	6
SIGALRM	Signal raised by alarm	14
SIGBUS	Bus error: "access to undefined portion of memory object"	7
SIGCHLD	Child process terminated, stopped (or continued*)	17
SIGCONT	Continue if stopped	18
SIGFPE	Floating point exception: "erroneous arithmetic operation"	8
SIGHUP	Hangup	1
SIGILL	Illegal instruction	4
SIGINT	Interrupt	2
SIGKILL	Kill (terminate immediately)	9
SIGPIPE	Write to pipe with no one reading	13
SIGQUIT	Quit and dump core	3
SIGSEGV	Segmentation violation	11
SIGSTOP	Stop executing temporarily	19
SIGTERM	Termination (request to terminate)	15
SIGTSTP	Terminal stop signal	20
SIGTTIN	Background process attempting to read from tty ("in")	21
SIGTTOU	Background process attempting to write to tty ("out")	22
SIGUSR1	User-defined 1	10
SIGUSR2	User-defined 2	12
SIGPOLL	Pollable event	29
SIGPROF	Profiling timer expired	27
SIGSYS	Bad syscall	31
SIGTRAP	Trace/breakpoint trap	5
SIGURG	Urgent data available on socket	23
SIGVTALRM	Signal raised by timer counting virtual time: "virtual timer expired"	26
SIGXCPU	CPU time limit exceeded	24
SIGXFSZ	File size limit exceeded	25