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].)
SIGKILL to a pid is no guarantee of killing it. If it's stuck in a syscall or already zombied (
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
SIGINT or other signals cleaning up after it, and having a bunch of disowned processes to cleanup (remember mongrel?) is annoying.
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)