Kill: The Command to End All Commands

Need to get rid of a job that's gotten into a loop and refuses to end? Here's a command that will take care of the problem.

Linux is a powerful operating system. With its demand-paged memory management and swap file facility, it lets you start as many processes as you choose. Of course, that number is subject to overall system memory capacity (physical memory plus swap) and your CPU's ability to perform all the tasks you have requested. Starting processes is easy, and when things slow to a crawl, stopping them is just as easy.

The Linux kill command is one of two that will meet your need when you grow tired of waiting for a process to terminate. With it, you can, in the words of my 1992 Linux Programmer Manual, terminate a process with extreme prejudice. All you need to know is a number called the process PID. Note that kill doesn't always terminate another process. In essence, kill sends a signal to a specified process. If that signal is not caught and handled by the process (not all can be), the process is terminated. All of the resources that were in use by the process are released for use by other running processes.

Processes and PIDs

What are processes, PIDs and signals? How are they discovered?

Recall that Linux is a multi-tasking operating system. When Linux boots, it starts a program called init, which in turn starts other programs. Many of these are background tasks like update, which periodically flushes data to the disk. Another example is getty, which watches a serial port for some sign of activity. A more visible example is the shell you use to perform useful work. It runs in the foreground, which means that it waits on your keystrokes. Each copy of each program running on your system is called a process.

Just as the US government passes out Social Security Numbers (we use Social Insurance Numbers here in Canada) to uniquely identify each individual, Linux assigns each process a unique number as an identifier. This number is called the process ID or PID.

When a process is started, it is given the next available PID, and when it terminates, its PID is released for eventual re-use. To determine the PID of any process belonging to you, enter ps at the prompt. The ps command will print, for each of your processes, a line containing the process's PID, the amount of time the process has used and the command with which the process was started. The output from ps looks like:

 6651  p0 S      0:01 -ksh<\n>
 6661  p1 S      0:00 -ksh
 6738  p2 S      0:00 -ksh
 6746  p2 S      0:00 wheel
 6747  p2 S      0:00 wheel
 7002  p0 S      0:01 elm
 7193  p1 R      0:00 ps

Signals are a form of process communication. Because they can come from another process, the kernel or the process itself, they might be better thought of as events that occur as a program runs. A crude example might be the bell most of us remember from our early days in school; when the bell rang, we reacted by switching from playful children to industrious students.

The signals we will use below are the termination signal SIGTERM, the interrupt signal SIGINT and the kill signal SIGKILL. These signals usually occur because another process sent them. You probably already use one of them; typing ctrl-c sends the interrupt signal SIGINT to your current foreground process. Other signals—such as SIGPIPE, which is sent to a process writing to a broken pipe—usually come from the kernel. There are about 30 signals, all of which can be referred to by numbers or by names, but the numbers change between platforms and some signals are unavailable on some platforms. The complete list of signals can be found on the signal(7) manual page; enter man 7 signal to see it or enter kill -1 for a short version of this list.

For each signal there is a default action, almost all of which terminate the process. For most signals, a program may specify another action—this is called catching or handling the signal—or may specify that no action occurs, which is called ignoring the signal. The signal SIGKILL cannot be caught or ignored; it always terminates processes.

For example, suppose you use cat to list a large text file without first determining the size of the file. Instead of watching hundreds, perhaps thousands of lines scroll by too quickly to read, you send the cat process the interrupt signal by pressing Ctrl-c. Fortunately, cat was not programmed to catch SIGINT, and the cat process is terminated immediately.



Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Kill child processes

Anonymous's picture

I am trying to kill all child processes without the parent. Lets just say it is bash that is running multiple times. I want to kill all of the child processes for bash but leave the parent running. Does anyone know how I can do that. I have tried the multiple commands and they either don't work or they kill everything. Any suggestions?

Kill Commands

Anonymous's picture

I am trying to kill all child processes without the parent. Lets just say it is bash that is running multiple times. I want to kill all of the child processes for bash but leave the parent running. Does anyone know how I can do that. I have tried the multiple commands and they either don't work or they kill everything. Any suggestions?

kill by process name

Anonymous's picture

To kill by process name, use pkill -signal

pkill processname -signal

Anonymous's picture

pkill processname -signal

I always thought that kill

Anonymous's picture

I always thought that kill -SIGKILL would kill any process, until I started plugging USB drives into my machine. I keep having problems where they lockup and cannot be listed, unmounted or anything else. If I do an ls on the mounted file system, it never comes back. I can find the process id of the ls process, but kill -9 on that process id does nothing. Anyone have something stronger than kill -9?

i'm running leopard on my

olson's picture

i'm running leopard on my AlBook G4 1.5 how do you use the process name i.e. "safari" "firefox" in conjunction with kill/killall?

One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix