Why doesn't kill work?
deron.meranda at gmail.com
Mon Feb 21 04:16:08 UTC 2005
On Sun, 20 Feb 2005 20:38:05 -0700, James McKenzie
<jjmckenzie51 at earthlink.net> wrote:
> I try in order:
> kill <pid>
> kill -2 <pid>
> kill -15 <pid>
> kill -9 <pid>
You should really use the symbolic symbol names (use kill -l to list them).
kill -s INT
kill -s TERM
kill -s KILL
The SIGINT signal is usually what Control-C sends, and typically indicates
a keyboard/interactive interrupt. It may or may not terminate a program,
depending on what the program desires to do. SIGTERM is the standard
signal used to tell a program to shut down (and is the default one sent by
the kill command if no signal is specified). SIGKILL is usually the
it will imemdiately kill any processes that is killable (and will not allow the
program to clean up after itself).
There are also a couple other signals that sometimes are used to shut down
processes: SIGHUP is automatically sent to all child processes of your shell
when you log out of your shell; and so most interactive commands will cleanly
shut down when receiving it (just like a SIGTERM). SIGQUIT is also
sometimes used to tell processes to shut down, but is usually more abrupt
than SIGTERM or SIGHUP, almost like an emergency shutdown rather
than a graceful shutdown.
Be aware of killing processes more harshly than necessary. Never just do
a kill -9 (SIGKILL) unless you've tried everything else first! You could
perhaps leave lock files laying around, or even cause corrupted files or
databases (and you don't want to chance corrupting your RPM database).
Note that the behavior of Control-C in a shell is really a property of the
pseudo-tty driver. You can in fact change it to use another key. Try
running "stty -a" to list the current "special" keys. The "intr" is the
keystroke that causes an interrupt (SIGINT). The "quit" keystroke
(usually Control-\) sends a SIGQUIT...which will usually terminate
most programs, even those that ignore or trap Control-C.
> However this would not kill a DEFUNCT process. Anyone got an idea on
> how to do this?
Defunct processes (also called zombies) are already dead, and thus
can't be killed again.
If you see defunct processes showing up in your process listing,
then look to see what the parent process is. The defunct process
entry will disappear either when the parent is itself killed, or if
the parent process reaps it. Other than consuming a slot in the
process table, a defunct process otherwise consumes no system
resources--no CPU, no disk, no files, and no memory (except
perhaps just a small handful of bytes).
You only need to worry about defunct processes if they tend
to stick around a long time and you accumulate a lot of them;
in which case it's the parent process that is to blame.
More information about the users