Occasionally, an unresponsive process may hinder the normal operation of your GNU/Linux system. Being able to identify the process IDs (PIDs) of these processes and stop them is an important part of administering a system.
Note: If you are not familiar with the GNU/Linux command line interface, review the Conventions page before proceeding.
If you know the exact name of the command associated with a problematic process, you can use the
ps -C command to find its associated PID(s).
ps -C example_command_name
For example, if the command name is
firefox-esr, you can find its associated PID like so:
$ ps -C 'firefox-esr' PID TTY TIME CMD 10882 tty2 00:00:38 firefox-esr
Above, you can see that the
firefox-esr command is associated with a process that has a PID of
If you are not sure of a problematic process's command name, the
pgrep command is an efficient alternative.
pgrep, or process grep (Global Regular Expression Print), provides the PID(s) associated with a given target, which can be a variety of things (e.g., a command name, a username, or a terminal).
The target you provide is an extended regular expression that matches against command names and command lines, and makes
pgrep more flexible than a simple
ps -C command.
For example, you can redo the prior example by using the string
fox as the
$ pgrep 'fox' 10882
For more informative output, you can add the
$ pgrep -a 'fox' 10882 /usr/lib/firefox-esr/firefox-esr
pgrep's useful options are:
- Display the full command line for the specified command, as well as the PID
- Consider only processes belonging to the group given as an argument to the option; groups can be given as group names or group IDs (GIDs); multiple groups are given as a comma-separated list (
- Display the command name, as well as the PID
- Select only the newest (most recently started) of the found processes
- Select only the oldest (least recently started) of the found processes
- Consider only processes whose parent process is the PID given as an argument to the option; multiple parent processes are given as a comma-separated list
- Consider only processes whose controlling terminal is listed as an argument to the option; terminal names should be given without the leading
- Consider only processes with the effective user ID (EUID) given as an argument to the option; multiple EUIDs are given as a comma-separated list; a username can be specified too
- Consider only processes with the real user ID (RUID) given as an argument to the option; multiple RUIDs are given as a comma-separated list; a username can be specified too
On a GNU/Linux system, there are numerous signals that act as software interrupts. These signals provide a way for a process (or a user) to communicate with a process, i.e., inter-process communication (IPC).
These are some of the most used signals:
||Hang up, or shut down and restart a process|
||Interrupt a process (Control+c)|
||Kill the process immediately (cannot be ignored/trapped)|
||Kill the process (can be ignored/trapped)|
||Lets a process that was stopped using
||Stop Execution until a
||Stop the terminal (Control+z)|
How a process reacts to a signal depends on the signal and the kind of process that receives the signal.
For example, background processes that provide services without a controlling terminal (i.e., daemons) usually re-read their configuration files without a restart when they are sent a
SIGHUP signal. On the other hand, most user space processes often die.
SIGSTOP signals are handled by the kernel and cannot be ignored or trapped with the
trap command. However, the
init process (and only the
init process) can ignore the
The exit status of a process tells you whether or not the process was terminated by a signal. If it was, the exit status will be
128, plus the number associated with the signal (e.g.,
143 is the exit status for a process that was terminated by the
You can terminate a process by providing a PID to the
kill sends a
SIGTERM signal. However, you can change this by specifying a different signal on the command line.
kill -example_signal example_PID
-example_signal can be either the symbolic or numeric signal name (e.g.,
-9). The numbers associated with these signals may differ between GNU/Linux distributions, so you may be better off using the signal name when you need to specify a signal.
You can view all available signals with the
kill -l command.
killall command kills all processes associated with a given command name.
As with the
killall sends the
SIGTERM signal by default, but you can change that by specifying a different signal on the command line.
killall options include:
- Kill the process group to which the process belongs; the kill signal is only sent once per group
- Interactively ask for confirmation before killing a process
- Do case insensitive command name matches
- Output a list of all available signals
killallto interpret the command name as an extended regular expression
- Kill only processes that the user given as an argument to the option owns; command names are optional
- Wait for all killed processes to die;
killallwill check once per second to see if any killed processes still exist and only return if none are left;
killallmay wait forever if the signal was ignored, had no effect, or if the process stays in a zombie state
pkill provides a more flexible way of killing associated processes. Instead of just supporting a command name as an argument, you can use a variety of other attributes for the command's target (e.g., username, terminal). As with the pgrep command, the target you provide is an extended regular expression that matches against command names and command lines.
SIGTERM is used for the default signal, but you can change that by specifying a different signal on the command line.
You can be very specific when using the
pkill command. For example, the following sends a
SIGKILL signal to commands that match the expression
sshd and whose EUID is root:
pkill -SIGKILL -u root sshd
pkill has the same options as the