Now and then a program (a "process") will need to be killed. It got annoyingly slow, or got stuck somehow. In Windows, the final solution for killing a process is "alt-ctrl-delete" which may or may not give you the capacity to shut down a process, and if that works, it requires a lot of struggling with dialog boxes, etc. Best case scenario in Windows is that the process dies cleanly. Often, a Windows process will leave messy bits and pieces of itself behind that may affect performance or create security problems, and often, the worst case scenario happens ... you've got to "kill" the process hard, by turning off the power or yanking the cord from the wall or throwing the computer into the nearest lake.
In Linux, nothing actually goes wrong, of course.
But when it does, you need to learn to kill a process. In the vast, vast majority of cases, the kill will be clean and a reboot will not be necessary. If you think a process, or killing a process, causes you to require a reboot, you should look into the possibility that something else more deeply screwy is going on, like that squirrels have moved into your computer or something along those lines. There are linux computers that have been running for years and have never been rebooted, even with system upgrades. There is one computer in the British Museum of Natural History that was pilfered by early archaeologists, believed to be one of the first Linux systems from the fifth dynasty of Egypt, that is still running, presumably on batteries from Atlantis.
The tools that you can play around with for this are top, kill, ps, and pkill. You will ultimately use pkill most of the time, but pkill needs to know the "name" of the process you are taking a contract out on, and the other tools can help with that.
So go ahead and start a program that you don't mind killing. For instance, the gnome dictionary utility that may or may not be installed on your toolbar. This will be the process to kill.
Now open a terminal window and type in "top"
This starts a program that lists every single processes you have access to and many you don't have access to. Top is one of those cool terminal based programs that looks like a gui but since it is not a gui, it is crispy and works all the time.
Try to find the target program. It is probably not visible because there is too much stuff running and since the software is likely not too busy it is probably way down on the bottom of the list .
So type a "u" and Top will ask you for which user's processes you want to see. Type in your user name. Now you will see that there are only your processes listed, but there is still a large number of them, probably way too many to find the target process. But it is cool to see how many processes their are that are all yours, and you didn't even know about them. If you go and fiddle with the target program (I just went and looked up a word in the Gnome Dictionary utility) the process will jump to the top of the pile and become briefly visible (the default sort order is CPU usage). You can use the buttons to change the column the data are sorted on, and "R" to reverse the sort order. This might help you find the process you want to kill.
Once you find the process on top, you can type "k" for kill, and up near the top of top it will say "PID to kill:" ... here is where you type in the number from the PID column of the process to kill. This works but is a pain because it is hard to find the process.
Suppose you have a process that often gets stuck and you often want to know its PID number. Here's a neat (though as we'll see in a moment unnecessary) trick to do this. Grep a batch version of the top command using part of the likely name of the process. The grep command can be used to isolate a line of text in a text stream based on the presence of a string on that line. Top, however, is not a data stream, but rather, one of these fake GUI programs. But it has "batch" mode.
This simply spits out the entire stream of process data every second or two until you figure out how to stop it (you may well end up having to "kill" top. So you can "pipe" (using a pipe, or a "|") the output of top's batch mode to grep. The command for my search of a dictionary program might be:
top -b | grep "dict"
I'm guessing that the string "dict" is part of the file name, and indeed, it is. Good thing I did not choose "dictionary" because the process name turns out to be gnome-dictionar (no y!).
Anyway, I can see my process id from this output, stop the top batch mode by frantically pressing various buttons such as control-c and control-d until it stops, or even better, just close that terminal window when I'm done with it. I can, for instance, have regular top running in one window and top -b | grep "whatever" running in another, use the info form the later to kill the process in the former, then just shut both terminal windows.
However, "top", as it turns out, is not really a nice *xnix program. It's actually a program based on other programs that are more relevant to what you want to use. For instance, there is a program called ps that simply lists all the processes. Open a terminal window, and type in ps. You get a fairly useless list of programs including the terminal window itself and the ps command itself and possibly nothing else. It is only telling you what is running in this terminal. So try typing in:
the "-e" stands for "everything" ... and will cause ps to print out a full list of processes.
To find a particular process, grep the list with a guess of the process name, for instance:
greg@greg-laptop:~$ ps -e | grep "dict"
7451 ? 00:00:00 gnome-dictionar
The second line is the output. Cool.
Now, I can kill the dictionary with a simple kill command:
Here, I've killed the process using the number that I learned from grepping ps, then re-grepped ps and got nothing back, meaning that the process is dead, nice and clean-like.
But wait, there's more. If you know the name of the process, you can kill it with the command pkill, like this:
Here I've grepped ps to show that gnome-dictionar is running, then I killed it by referring to its name with pkill, then checked and ding-dong, the dictionary is dead. The first and third steps here were not necessary, I just wanted to show you that gnome-dictionar was there, then gone. Its like bringing back a finger or an ear.
There are other ways to kill things, including a utility that sits on your gnome toolbar, with an icon that looks like a window breaking in half . You pick that icon and touch any program with it, and this give you the option to "force" an application closed.
I do that when I need to, but I also like killing stuff from the terminal. It is simply more fun.
On a final note, I mentioned above that the "-e" option in ps meant "everything" ... I was only kidding, just pushing troll buttons. It actually means "every process."
One other thing. Don't "kill all" or pkill with wildcards. Both commands may well work on your system. A good hit-man does not use a hand-grenade. Why should you?
There is also xkill that lets you select a gui program to kill.
I use some non-native programs that do not always respond to the default kill command when they become unresponsive. I have to use "kill -9 " in that case. It doesn't do a proper cleanup, but it works as a last resort.
Yes! xkill with no process ID number gives you a cool skull and crossbones cursor. Whatever you touch with it dies.
man xkill gives us:
" This program is very dangerous, but is useful..."
There are ways to kill processes from a GUI. In KDE, use KSysGuard. It has two tabs, one for system load, and the other for process table. Click the process you don't like and hit the kill button. Gnome must have something similar.
What do you do if the x server hangs on shutdown? Other than pull the power with a menacing spork?
I supposed it depends on where in shutdown you are. You could hit ctrl-function key (try various ones) to get a terminal and then kill the x server from a distance.
When all else fails you need to "kill -9."
depending on how your X11 is configured, it may listen to ctrl-alt-backspace. that hotkey --- unless it's been disabled, which is rare --- kills off the X server (the GUI part of the OS alone), which can lead to either a restart of the GUI dumping you at the log-in screen (the usual result) or a text-mode-only user interface (rarer).