Killing processes willy-nilly is not a smooth move: data can be lost, poorly-designed apps can break themselves in subtle ways that cannot be fixed without a reinstall.. but it completely depends on knowing what is and what is not safe in a given situation.
and what would be at risk. The user should have some idea what a process is, or should be, doing and what it's constraints are (disk IOPS, rss/swap) and be able to estimate how much time a long-running process should take (say a file copy, mp3 reencoding, email migration, backup, [your favorite timesink here].)
Furthermore, sending SIGKILL
to a pid is no guarantee of killing it. If it's stuck in a syscall or already zombied (Z
in ps
), it may continue to be zombied. This is often the case of ^Z a long running process and forgetting to bg
before trying to kill -9
it. A simple fg
will reconnect stdin/stdout and probably unblock the process, usually then followed by the process terminating. If it's stuck elsewhere or in some other form of kernel deadlock, only a reboot may be able to remove the process. (Zombie processes are already dead after SIGKILL
is processed by the kernel (no further userland code will run), there's usually a kernel reason (similar to being "blocked" waiting on a syscall to finish) for the process not terminating.)
Also, if you want to kill a process and all of its children, get into the habit of calling kill
with the negated PID, not just the PID itself. There's no guarantee of SIGHUP
, SIGPIPE
or SIGINT
or other signals cleaning up after it, and having a bunch of disowned processes to cleanup (remember mongrel?) is annoying.
Bonus evil: kill -9 -1
is slightly more damaging than kill -9 1
(Don't do either as root unless you want to see what happens on a throw-away, non-important VM)