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.