Although Linux is considered to be a robust operating system that does not have many issues with applications, programs sometimes become unresponsive or fail to respond. When this happens, they can consume a great deal of system resources, and ultimately take down the entire system. These applications usually cannot be restarted automatically; however, as the process in question may still be running and will not get shut down completely, we need to use a command to terminate the process. When this happens, it is necessary to either restart the whole system or kill off the specific application process. Since restarting the entire system takes time and can create significant inconvenience for the clients, it is much easier to simply kill the process itself.
What is a Process?
A process is the working mechanism of a program that is currently being executed. Upon its creation, every process is automatically assigned a unique process identification number, also known as a PID. When a process dies, its PID is returned to the pool of available PIDs, and another process can then reuse it.
We can use multiple commands on a server to find a specific PID of a process. We can use the top command, which will give us a table of all the running processes, where we can find the PID of a process along with other useful system information.
Another way to find the PID is with the ps command. We can use ps in a few different ways:
[root@host ~]# ps faux | grep systemd Root 1 0.0 0.6 96656 11260 ? Ss Jan24 0:08 /usr/lib/systemd/systemd --switched-root --system --deserialize 18 Root 533 0.0 1.3 125588 22832 ? Ss Jan24 0:25 /usr/lib/systemd/systemd-journald Root 564 0.0 0.5 107440 9248 ? Ss Jan24 0:00 /usr/lib/systemd/systemd-udevd Dbus 684 0.0 0.3 73540 5524 ? Ss Jan24 0:06 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only Root 743 0.0 0.4 95736 7760 ? Ss Jan24 0:01 /usr/lib/systemd/systemd-logind Root 66199 0.0 0.0 12108 1060 pts/0 S+ 08:28 0:00 \_ grep --color=auto systemd Root 66153 0.0 0.5 93212 9472 ? Ss 08:27 0:00 /usr/lib/systemd/systemd --user [root@host ~]#
[root@host ~]# ps -eo user,pid,command | grep systemd [root@host ~]# ps -eo user,pid,command | grep systemd root 1 /usr/lib/systemd/systemd --switched-root --system --deserialize 18 root 533 /usr/lib/systemd/systemd-journald root 564 /usr/lib/systemd/systemd-udevd dbus 684 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only root 743 /usr/lib/systemd/systemd-logind root 66153 /usr/lib/systemd/systemd --user root 66213 grep --color=auto systemd [root@host ~]#
We can also use the pidof process_name, and the pgrep process_name commands to find out the corresponding PIDs of that process.
[root@host ~]# pidof systemd 66156 66153 1 [root@host ~]#
[root@host ~]# pgrep systemd 1 533 564 743 66153 [root@host ~]#
To terminate a process, we can use the kill command. This is a built-in command that sends a signal to a specified process, which terminates the process in question.
What Are Signals?
Signals are a form of dialogue between the processes that can come from other processes, the kernel, or the process itself. Each process has a current behavior, of which there are five types. The five dispositions are as follows:
These attributes determine how the process will behave when a signal is delivered to it. The Term’s default action is to terminate the process, and it is the one primarily used by the kill command.
There are a total of sixty-four (64) signals. The one we send will depend on the result that we want, as different signals have different effects and outcomes. Out of these sixty-four signals, the first thirty-one are standard signals, and the last thirty-three real-time signals numbered from thirty-two to sixty-four. We can see a full list of available signals with the command kill -l or in the signal manual page by entering man 7 signal.
[root@host ~]# kill -l 1) SIGHUP 2) SIGINT 3) SIGQUIT 4) SIGILL 5) SIGTRAP 6) SIGABRT 7) SIGBUS 8) SIGFPE 9) SIGKILL 10) SIGUSR1 11) SIGSEGV 12) SIGUSR2 13) SIGPIPE 14) SIGALRM 15) SIGTERM 16) SIGSTKFLT 17) SIGCHLD 18) SIGCONT 19) SIGSTOP 20) SIGTSTP 21) SIGTTIN 22) SIGTTOU 23) SIGURG 24) SIGXCPU 25) SIGXFSZ 26) SIGVTALRM 27) SIGPROF 28) SIGWINCH 29) SIGIO 30) SIGPWR 31) SIGSYS 34) SIGRTMIN 35) SIGRTMIN+1 36) SIGRTMIN+2 37) SIGRTMIN+3 38) SIGRTMIN+4 39) SIGRTMIN+5 40) SIGRTMIN+6 41) SIGRTMIN+7 42) SIGRTMIN+8 43) SIGRTMIN+9 44) SIGRTMIN+10 45) SIGRTMIN+11 46) SIGRTMIN+12 47) SIGRTMIN+13 48) SIGRTMIN+14 49) SIGRTMIN+15 50) SIGRTMAX-14 51) SIGRTMAX-13 52) SIGRTMAX-12 53) SIGRTMAX-11 54) SIGRTMAX-10 55) SIGRTMAX-9 56) SIGRTMAX-8 57) SIGRTMAX-7 58) SIGRTMAX-6 59) SIGRTMAX-5 60) SIGRTMAX-4 61) SIGRTMAX-3 62) SIGRTMAX-2 63) SIGRTMAX-1 64) SIGRTMAX [root@host ~]#
For most of these signals, a program may or may not specify a different action. If the action is defined, it is called catching or handling the signal, but if no action occurs, then the signal will be ignored.
The most commonly used signals are:
|Signal Name||Single Value||Effect|
|SIGHUP||1||Hangup, reload a process|
|SIGINT||2||Interrupt from keyboard|
|SIGKILL||9||Kill a process|
|SIGTERM||15||Terminate a process gracefully|
|SIGSTOP||17, 19, 23||Stop a process|
The SIGKILL and SIGSTOP signals cannot be caught, blocked, or ignored, while the SIGTERM signal can be caught or ignored. That is why we can use SIGKILL when SIGTERM fails to stop or end the process.
[root@host ~]# ps -eo user,pid,command | grep java tomcat 59815 /usr/bin/java -Djava.util.logging.config.file=/usr/local/tomcat9/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.net.preferIPv4Stack=true -Djava.net.preferIPv4Addresses=true -Djdk.tls.ephemeralDHKeySize=2048 -Djava.protocol.handler.pkgs=org.apache.catalina.webresources -Dorg.apache.catalina.security.SecurityListener.UMASK=0027 -Dignore.endorsed.dirs= -classpath /usr/local/tomcat9/bin/bootstrap.jar:/usr/local/tomcat9/bin/tomcat-juli.jar -Dcatalina.base=/usr/local/tomcat9 -Dcatalina.home=/usr/local/tomcat9 -Djava.io.tmpdir=/usr/local/tomcat9/temp org.apache.catalina.startup.Bootstrap start root 66401 grep --color=auto java [root@host ~]# kill -15 59815 [root@host ~]#
Unfortunately, the kill -15 (SIGTERM) did not accomplish stopping the Java process.
Using The Kill Commands
As noted above, the kill command sends a signal to terminate a process. By default, it will send a TERM signal, if no other signal is defined. That signal will try to stop the process gracefully. If that fails, because the signal may have been caught or ignored, we can try terminating the process with another signal. To kill a process with a different signal, it can be defined using a number (-9), with a SIG prefix (-SIGkill) with or without the SIG prefix (-kill).
[root@host ~]# ps -eo user,pid,command | grep java tomcat 66469 /usr/bin/java -Djava.util.logging.config.file=/usr/local/tomcat9/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.net.preferIPv4Stack=true -Djava.net.preferIPv4Addresses=true -Djdk.tls.ephemeralDHKeySize=2048 -Djava.protocol.handler.pkgs=org.apache.catalina.webresources -Dorg.apache.catalina.security.SecurityListener.UMASK=0027 -Dignore.endorsed.dirs= -classpath /usr/local/tomcat9/bin/bootstrap.jar:/usr/local/tomcat9/bin/tomcat-juli.jar -Dcatalina.base=/usr/local/tomcat9 -Dcatalina.home=/usr/local/tomcat9 -Djava.io.tmpdir=/usr/local/tomcat9/temp org.apache.catalina.startup.Bootstrap start root 66516 grep --color=auto java [root@host ~]# kill -9 66469 [root@host ~]# [root@host ~]# ps -eo user,pid,command | grep java root 66530 grep --color=auto java [root@host ~]#
As you can see, the kill -9 (SIGKILL) command terminated the Java process.
The kill command can be invoked with the following syntax:
kill [OPTIONS] [PID]
For example, if we find that the process ID for a httpd process is 21567, we can try to kill it gracefully by invoking:
[root@host ~]# kill 21567
This will send the TERM signal. If this does not stop the process, we can then try to kill it with the signal SIGKILL (-15), which will kill it without first waiting for the process to be properly closed. This can be accomplished in one of the following ways:
[root@host ~]# kill -9 21567 [root@host ~]# kill -SIGKILL 21567 [root@host ~]# kill -kill 21567
Additionally, we can kill a process by using the unique process ID, by using the kill command, or with the process name, by using the killall command. The same syntax is applied with the killall command, which can be invoked with killall [signal] [process_name], for example:
killall -9 httpd
This command will terminate the httpd process without waiting for it to stop gracefully. When determining which process the signal will be sent to, it will match the argument name exactly.
The command will send a termination signal to all processes that are exactly named “httpd.” If we try to run this command:
It will show an error that there is no process with that name since Apache uses “httpd” as the process name as opposed to “http.”
A command similar to killall is pkill, which also can kill a process by name. This command takes a pattern as an argument, which is then matched against the names of running processes, so it doesn’t need an exact name. For example, we can terminate httpd with something like this:
Although this is not the exact process name, it will find the processes that contain this pattern and send the terminate signal to httpd.
The skill command can also be used (using the same syntax as the kill command) to send termination signals, much like kill command. The default TERM signal is primarily used here.
skill [signal] [options] [root@host ~]# ps -eo user,pid,command | grep tomcat tomcat 66546 /usr/bin/java -Djava.util.logging.config.file=/usr/local/tomcat9/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.net.preferIPv4Stack=true -Djava.net.preferIPv4Addresses=true -Djdk.tls.ephemeralDHKeySize=2048 -Djava.protocol.handler.pkgs=org.apache.catalina.webresources -Dorg.apache.catalina.security.SecurityListener.UMASK=0027 -Dignore.endorsed.dirs= -classpath /usr/local/tomcat9/bin/bootstrap.jar:/usr/local/tomcat9/bin/tomcat-juli.jar -Dcatalina.base=/usr/local/tomcat9 -Dcatalina.home=/usr/local/tomcat9 -Djava.io.tmpdir=/usr/local/tomcat9/temp org.apache.catalina.startup.Bootstrap start root 66846 grep --color=auto tomcat [root@host ~]# skill -9 66546
It is recommended to use the kill, pkill, or killall commands instead.
Another command that will end a process that matches a specific pattern is mysql_zap. An identified process will match this pattern if its output line from the ps command contains that pattern. As with other commands, mysql_zap will send a TERM signal by default, unless another signal is specified. The syntax used for this command is:
[root@host ~]# mysql_zap [signal] [pattern].
It should be noted that the mysql_zap command has been depreciated in MariaDB as of version 10.2 in favor of the pkill command that can be used as an alternative.
The mk-kill command is used to kill MySQL queries that match a specified criterion. If a file is passed to mk-kill, it will read the queries from that file, which should contain the output of SHOW PROCESSLIST. If no file is given as an argument, mk-kill will execute a SHOW PROCESSLIST in MySQL to obtain the queries. Here are two examples of that command:
[root@host ~]# mk-kill --busy-time 60 --print [root@host ~]# mk-kill --match-command Sleep --kill --no-only-oldest --interval 10
The first command will kill any queries found to be running longer than sixty seconds. The second command checks for any sleeping processes every ten seconds, and if any are found, the mk-kill command ends those queries.
Another command related to mk-kill is the mkill command. This command will kill slow queries where found. It will kill these queries based on several factors, such as query time, host, user, database, state, and query content. It should be noted that the mkill command is still in an alpha version status.
If we would like to kill a specific thread, instead of an arbitrary thread within an entire process, we can do so with tkill and tgkill commands. We should note that the tkill command should be avoided as it is the depreciated predecessor to tgkill. The tkill command only allows for the target thread ID to be specified, which could lead to the termination of an incorrect thread if that thread ID is recycled. On the other hand, tgkill will send a signal to the thread with the thread ID in the thread group tgid (the Thread Group ID).
It is also worth noting that several commands are used to send signals to a process group. One of those commands is killpg. The killpg command will send a signal to a process group (or pgrp). If the pgrp is 0, then a signal will be sent to the calling process’ process group. Otherwise, the killpgrp command does not take any other arguments so that it will kill all processes within the same process group.
We can also kill specific TCP connections that are in progress with the tcpkill command. Using this command, we can specify a network interface to listen on (as an option), or we can also determine the degree of force to use in terminating a connection, where the default is 3. The following command is the syntax of tcpkill.
[root@host ~]# tcpkill [-i interface] [-1...9] expression [root@host ~]# tcpkill -i eth0 port 21
If we need to stop a process running inside a virtualized container running on Ubuntu (e.g., if using k8s or docker), we can use the lxc-kill command. This command will send a numeric signal to the first process of the container to end a process. The syntax of the lxc-kill command is as follows.
lxc-kill --name=NAME SIGNUM
The arckill command is used to kill running jobs on an ARC enabled resource (an Advanced Resource Connector, which is a grid computing middleware). We can either use the jobid, or the jobname, if such an attribute was submitted, to refer to a job.
arckill -j filename.xml (<jobid#>)
To terminate a specified PVM process (a message-passing system), we can use the pvm_kill command. It will send a terminate signal to a PVM process that is identified by the task identifier tid. This command is primarily used with a larger program as is called like so:
- In C: info = pvm_kill( tid );
- In Fortran: CALL PVMFKILL( TID, INFO )
There is also the xkill command, which is a graphical way to kill an application. When you enter the command xkill, the mouse cursor will change into a plus sign (depending on your icon set), which allows us to left-click an unresponsive window to close it. The xkill command instructs the xserver to terminate the window displaying a program. Its syntax is as follows:
xkill [-display displayname] [-id resource] [-button number] [-frame] [-all]
There are other general rules when it comes to killing processes, and it is essential to note that regular users can send signals to their own processes, but not to those that belong to other users. The root user, on the other hand, can send signals to all other user’s processes.
- This also depends on what PID we pass to the command.
- If the PID is greater than zero, then the signal is sent to the process with that PID.
- If the PID is equal to zero, the signal is sent to all processes in the process group (PGID) of the shell that is invoking the kill command.
- If PID is equal to -1, the signal is sent to all processes with the same user ID as the user who has invoked the kill command.
- If PID is less than -1, the signal is sent to all processes in the process group with the process group ID that is equal to the absolute value of the PID.
As we can see, there are several ways that can be used to terminate a process. However, one should exercise caution when utilizing these commands to prevent incorrectly terminating a needed process that can kill an application that should not be killed. It could also cause an interruption to an essential service, which can lead to many issues. With that in mind, it is recommended to always consult the man pages for each command, or, if still not completely sure, get in touch with our Support team who will happily assist in this matter.
“Like an extension of my IT team” – Rapid Crush Case Study
As we continue to move forward into the future, your knowledge should grow as well in order to keep up with your competitors. To learn how one of our clients has capitalized on this idea, click here to download the case study detailing their journey!