Processes can ignore some signals. If you send SIGKILL it will not be able to ignore it (and neither catch it to do cleanups). Try:
kill -9 {PID}
Learn more by reading the manual page:
man kill
Open another terminal and run ps ax | grep foo
where foo is the name of the unresponsive program. This should return a line of output that looks something like this:
$ ps ax | grep firefox
2222 ? S 0:00 /bin/sh /usr/lib/firefox-3.6.9/firefox
2231 ? Sl 514:36 /usr/lib/firefox-3.6.9/firefox-bin
30290 pts/2 S+ 0:00 grep --color=auto firefox
The first field of each line of output is a number which represents the Process ID of the program matched by grep
(you can safely ignore the last one, which represents grep
itself.
To halt the offending process, do:
kill pid
where pid is the Process ID of the program. You might have to use your judgment as to which of the matches needs to be kill
ed, or you could use top
instead. Using kill
by itself sends SIGTERM, which you should try first as it allows the program to properly clean up after itself. If SIGTERM fails, try SIGHUP, which is stonger medicine: kill -HUP pid
. If all else fails, send SIGKILL. But, you should only do so as a last resort, because SIGKILL causes the kernel to terminate the process immediately with no possibility for cleanup. This can at times result in data corruption or other problems. So again, only send SIGKILL as a last resort. To do so, do kill -KILL pid
or kill -9 pid
.
If you are running a graphical interface, of course, you don't have to fool with this crazy command-line stuff to get the job done. Just open "System Monitor", navigate to the Processes tab, choose the process you want to halt (Hm, could it be the one using 90% CPU?) and right-click it. Since the process is already stopped, (that's the problem, right?) choose End Process or Kill Process from the resulting menu.
Credit to koanhead
Best Answer
You can get that process's standard file descriptors, e.g.
stdout
: