Stopping Runaway Applications in Linux

3772

 

With Linux comes great power — and great control. When you’re running Linux, you have thousands of applications, utilities, and commands at your fingertips — and ultimate control over those applications as well. When they start, how they start, and (more importantly) how they stop. Let’s take a look at some of the commands and utilities you have to master your Linux systems.

Most Windows users are familiar with the Task Manager. When a process goes awry the user opens the Task Manager and clicks like mad in an attempt to get the process to finally end. When that process does finally end (if it ends), the unsuspecting user is prompted to send a report to Microsoft. Linux, on the other hand, has many ways to kill applications that have gone astray. From the command line, all the way to the GUI, Linux is a real champ when it comes to managing those processes.

Managing Processes From the Command Line

As expected, the Linux operating system really shines when managing processes from the command line. But before issuing commands to kill those applications, it’s important to have at least a basic understanding of how things work.

Every process on the Linux operating system is associated with (among other things) a name and a Process ID (PID). The name will be something like /usr/bin/chromium-browser and the PID will be a number such as 10722. It is possible to kill the same application, from the command line, in two different ways:

  • Using the process name with the killall command.
  • Using the PID with the kill command.

How does one decide which of the above commands to use? That’s a simple question. If the PID is known, kill the process with the kill command. If the PID is not known, kill the process with the killall command. Of course, it’s quite easy to find the PID, but that does mean an extra step. Extra steps, however, always means something new can be learned.

Killing a Process Using the kill Command

Before the kill command can be used, the Process ID must be known. To find out the PID, an all together different command must be used. Sticking with the browser theme, to find out the PID of the application midori, the ps command will be used like so:

ps aux | grep midori

The output for the above command will look something like that shown in Figure 1. Let me explain what is shown.

Figure 1
For clarification, Midori is a light-weight web browser.

In the above example, the command ps is run using the options:

  • a: Select all processes except session leaders and processes not associated with a terminal.
  • u: Select by user ID.
  • x: Format output in register format.

The ps command is also piped through the grep command in order to only display output associated with the command midori. This limits the output to only those commands related to the midori command. The output clearly shows us two related entries. The first line of output is the one in question and the second line is actually the command just run. In the first line the PID is listed right after the username. So, in the example shown, the PID of midori is 17414. To kill that process using the kill command would look like:

kill 17414

Note that kill can be used to send a number of signals to running applications — not just the kill signal itself. What are signals? Signals are different ways to communicate to a process to instruct it to do specific things. To send a signal through the kill command, the format of the command looks like:

kill -s signal process

Where signal is the actual signal to send and process is the process the signal is sent to. Many signals have both a name and a number associated, such as the kill signal which is 9. Here are other, significant, signals that can be used (in the format signal_name signal_number explination):

  • HUP 1 Kill controlling signal.
  • INT 2 Send interrupt signal from keyboard.
  • KILL 9 Send the kill signal.
  • TERM 15 Send the terminate signal.
  • STOP 17, 19, 23 Send stop signal.
  • CONT 19, 18, 25 Continue if stopped.

Obviously, the above short list of signals all will end a process. The important factor is how each signal ends a process. Some of the above signals are forcible (1 and 9) whereas others can end a proces more gracefully (15, 17, and 19). If sending a forcible signal to a process could result in data loss or worse, the CONT signal could be sent to do a more graceful shutdown is in order.  In the case of signal 19, the process will do a sort of restart. Say, for example, a process has gone astray, but killing the process forcibly could end in disaster. Instead, send the CONT signal, like so:

kill -s 19 process

Where process is the actually process to be killed. It is also possible to kill (both forcibly and gracefully) daemons on the system. However, I highly recommend restarting daemons through the distribution inetd system, which allows for the stopping, starting, and restarting (or reloading) of the daemon. This is generally done, as the root user, like so (Using Fedora as an example):

/etc/rc.d/init.d/daemon start/stop/restart

Where daemon is the actual daemon to be managed and start/stop/restart is a choice between starting, stopping, or restarting the daemon.

Killing a Process Using the killall Command

Some do not like to work through the extra step of locating the PID (or may find themselves in a situation where that extra step could mean extra trouble), so the killall command is often used in place of kill. The killall command is quite simple to use:

killall process

Where process is the actual name of the process to be killed. Say, for example, the Midori browser has become unresponsive and is starting to cause a massive memory leak. To kill that application quickly, the command killall midori would do the trick. The only trick to killall is the exact name of the process must be known (such as firefox-bin and not firefox.)

Killing a Process Using a GUI

Many Linux users will prefer to use a graphical tool for the killing of rogue applications. Both the GNOME and KDE desktops offer an outstanding and user-friendly graphical tool for the managing of process. The GNOME system monitor is found by clicking System > Administration > System Monitor. When this tool opens (see Figure 2), a listing of running processes will be shown. To kill a process simply select the process and click the End Process button.

Figure 2
You can do much more than kill processes with this tool.

Similarly, KDE’s graphical system monitor can easily kill rogue processes. To start this tool click K > Applications > System > Monitor > System Monitor. The steps for killing an errant process are similar to that of the GNOME System Monitor:

  1. Open the tool (see Figure 3.)
  2. Scroll through the list of running process until the target process is found.
  3. Select the target process.
  4. Click End Process button.

KDE’s System Monitor also offers features other than killing processes.

Use These Tools Wisely

The kill and killall commands must be used with care as killing the wrong running process could quickly end your graphical session (example: killall gnome-session will instantly terminate your running GNOME session, and all of your running applications along with it.) It is always wise to make sure the application about to be killed is in fact the correct application.Figure 3

Finally, a last word of warning — killing an application will most likely end with data loss. There are some applications that will attempt to recover data when the application is restarted (such as LibreOffice and web browsers), but never count on that working in your favor. Ultimately, however, if an application is not responding to mouse clicks sometimes the only option is to issue either the kill or killall commands.