Once we’ve issued the above commands, all of the chrome processes will have been successfully killed. So to send the kill signal, we’d issue the commands: kill -9 3827 We already know, from our ps command that the IDs we want to kill are 3827, 3919, 10764, and 11679. Where SIGNAL is the signal to be sent and PID is the Process ID to be killed.
The structure for this command would be: kill SIGNAL PID So, let’s now use the kill command to kill our instance of chrome. So you don’t have to memorize all of the names of the various signals.
What’s nice about this is that you can use the Signal Value in place of the Signal Name. You’ll find quite a large number of signals (Figure 3). You can get a list of all the signals that can be sent to the kill command by issuing kill -l. This is always a wise choice when you need the process to immediately restart (such as in the case of a daemon). For instance, you can send the HUP (hang up) signal to the kill command, which will effectively restart the process. What signal you send will be determined by what results you want from the kill command. There are also different signals that can be sent to both kill commands. There are two commands used to kill a process: Which you use will determine the command used for termination. We have two pieces of information that will help us kill the errant process: Now we come to the task of killing the process. When you issue the command above, you’ll be given more information than you need (Figure 2) for the killing of a process, but it is sometimes more efficient than using top.įigure 2: Locating the necessary information with the ps command. The x option is important when you’re hunting for information regarding a graphical application. X = also show processes not attached to a terminal So this command would look like: ps aux | grep chrome We only want the listing associated with Chrome. The reason why we filter ps through grep is simple: If you issue the ps command by itself, you will get a snapshot listing of all current processes. The ps command reports a snapshot of a current process and grep prints lines matching a pattern. For that, you can make use of the ps command and filter the output through grep. Let’s say you know the Chrome process is what you need to kill, and you don’t want to have to glance through the real-time information offered by top. This information will be important to have with one particular method of killing the process.Īlthough top is incredibly handy, it’s not always the most efficient means of getting the information you need. According to our top display, we can discern there are four instances of chrome running with Process IDs (PID) 3827, 3919, 10764, and 11679. Say, for example, Chrome has become unresponsive. Figure 1: The top command gives you plenty of information.įrom this list you will see some rather important information. From the command line, issue top to see a list of your running processes (Figure 1).
With top, you get a full listing of currently running process. Top is a tool every administrator should get to know. There are two commands I use to locate a process: top and ps. The first step in killing the unresponsive process is locating it. I will be dealing strictly with the command line, so open up your terminal and prepare to type. The steps I’m going to outline will work on almost every Linux distribution, whether it is a desktop or a server. How do you take care of this layered task? It’s actually quite simple…once you know the tools at your disposal. However, before you immediately launch that command to kill the process, you first have to know what the process is. Thankfully, Linux has every tool necessary to empower you, the user, to kill an errant process. But how? Believe it or not, your best bet most often lies within the command line. You try to run the app again, but it turns out the original never truly shut down completely. Picture this: You’ve launched an application (be it from your favorite desktop menu or from the command line) and you start using that launched app, only to have it lock up on you, stop performing, or unexpectedly die.
For more great SysAdmin tips and techniques check out our free intro to Linux course. This is a classic article written by Jack Wallen from the archives.