Despite the fact that processes running on your computer are usually hidden away, Linux offers complete, unrestricted, and unapologetic control over them. You can terminate processes, change their properties, and learn every piece of information there is to know about them.
This provides ample scope for damaging the currently running system but, in spite of this, even standard users have complete control over processes that they personally started (there is one exception, so-called zombie processes, described a bit later in this section). As you might expect, the root user has control over all processes that were created by ordinary users, as well as those processes started by the system itself.
The user is given this degree of control over processes in order to enact repairs when something goes wrong, such as when a program crashes and won't terminate cleanly. It's impossible for standard users to damage the currently running system by undertaking such work, although they can cause themselves a number of problems.
This control over processes is what makes Linux so reliable. Because any user can delve into the workings of the kernel and terminate individual processes, any crashed programs can be cleaned up with negligible impact on the rest of the system.
Whenever you quit a program or, in some cases, when it completes the task you've asked of it, it will terminate itself. This means ending its own process and also that of any other processes it created in order to run. The main process is called the parent, and the ones it creates are referred to as child processes.
You can see a nice graphical display of which parent owns which child process by typing pstree at the command-line shell.
While this should mean your system runs smoothly, badly behaved programs sometimes don't go away. They stick around in the process list. Alternatively, you might find that a program crashes and so isn't able to terminate itself. In very rare cases, some programs that appear otherwise healthy might get carried away and start consuming a lot of system resources. You can tell when this happens because your system will start slowing down for no reason, as less and less memory and/or CPU time is available to run actual programs.
In all of these cases, the user usually must kill the process in order to terminate it manually. This is easily done using top.
The first task is to track down the crashed or otherwise problematic process. This can be done in top by looking for a process that matches the name of the program, as shown in Figure 17-2. For example, the Firefox web browser generally runs as a process called firefox-bin. The Konqueror web browser uses processes called konqueror.
Figure 17-2. You can normally identify a program by its name in the process list.
You should be absolutely sure that you know the correct process before killing it. If you get it wrong, you could cause other programs to stop running.
Because top doesn't show every single process on its screen, tracking down the trouble-causing process can be difficult. A handy tip is to make top show only the processes created by the user you're logged in under. This will remove the background processes started by root. You can do this within top by typing u, and then entering your username.
Once you've spotted the crashed process, make a note of its PID number, which will be at the very left of its entry in the list. Then type k. You'll be asked to enter the PID number. Enter that number, and then press Enter once again (this will accept the default signal value of 15, which will tell the program to terminate).
With any luck, the process (and the program in question) will disappear. If it doesn't, the process you've killed might be the child of another process that also must be killed.
To track down the parent process, you need to configure top to add the PPID field, for the parent process ID, to its display. To add this field, type f, and then b. Press Enter to return to the process list afterwards. The PPID column will appear next to the process name on the right of the window. It simply shows the PID of the parent process. You can use this information to look for the parent process within the main list of processes.
The trick here is to make sure that the parent process isn't something that's vital to the running of the system. If it isn't, you can safely kill it. This should have the result of killing the child process you uncovered prior to this.
If the PPID field in top displays a value of 1, that means the process doesn't have a parent process. In both the PPID and PID fields, you should always watch out for low numbers, particularly one-, twoor three-digit numbers. These are usually processes that started early on when Linux booted and that are essential to the system.
Zombie processes are those that are children of processes that have terminated. However, for some reason, they failed to take their child processes with them. Zombie processes are rare on most Linux systems.
Despite their name, zombie processes are harmless. They're not actually running and don't take up system resources. However, if you want your system to be spick-and-span, you can attempt to kill them.
In the top-right area of top, you can see a display that shows how many zombie processes are running on your system, as shown in Figure 17-3. Zombie processes are easily identified because they have a Z in the status (S) column within top's process list. To kill a zombie process, type k, and then type its PID. Then type 9, rather than accept the default signal of 15.
Figure 17-3. You can see at a glance how many zombie processes are on your system by looking at the top right of top's display.
There's no magic involved in killing processes. All that happens is that top sends them a "terminate" signal. In other words, it contacts them and asks them to terminate. By default, all processes are designed to listen for commands such as this; it's part and parcel of how programs work under Linux. When a program is described as crashed, it means that the user is unable to use the program itself to issue the terminate command (such as Quit). A crashed program might not be taking input, but its processes will probably still be running.
In many cases, zombie processes simply won't go away. When this happens, you have two options. The first is to restart the program that is likely to be the zombie's owner, in the hope that it will reattach with the zombie, and then quit the program. With any luck, it will take the zombie child with it this time. Alternatively, you can simply reboot your PC. But it's important to note that zombie processes are harmless and can be left in peace on your system!
You don't always need to use top to control processes. There are a range of quick and cheerful shell commands that can diagnose and treat process problems.
The first of these is the ps command. This stands for Process Status and will report a list of currently running processes on your system. This command is normally used with the -aux option:
This will return a list something like what you seen when you run top.
If you can spot the problematic process, look for its PID and issue the following command:
kill <PID number>
For example, to kill a process with a PID of 5122, you would type this:
If, after this, you find the process isn't killed, then you should use the top program, as described in the previous sections, because it allows for a more in-depth investigation.
There's another handy process-killing command that lets you use the actual process name. The killall command is handy if you already know from past experience what a program's process is called. For example, to kill the process called firefox-bin, which is the chief process of the Firefox web browser, you would use the following command:
Make sure you're as specific as possible when using the killall command. Issuing a command like killall bin will kill all processes that might have the word bin in them!
Sometimes, a crashed process can cause all kinds of problems. The shell you're working at may stop working, or the GUI itself might stop working properly.
In cases like this, it's important to remember that you can have more that one instance of the command-line shell up and running at any one time. For example, if a process crashes and locks up Konsole, simply start a new instance of Konsole using the K menu. Then use top within the new Konsole window to kill the process that is causing trouble for the other Konsole window.
If the crashed program affects the entire GUI, you can switch to a virtual console by pressing Ctrl+Alt+F2. Although the GUI disappears, you will not have killed it, and no programs will stop running. Instead, you've simply moved the GUI to the background while a shell console takes over the screen. Then you can use the virtual console to run top and attempt to kill the process that is causing all the problems. When you're ready, you can switch back to the GUI by pressing Ctrl+Alt+F8.