Software interrupts on Linux and Unix systems are made via signals. There are many different Linux signals, but a few stand out and are important to understand and know: SIGINT, SIGTERM, and SIGKILL. Here's how they work.

What Is a Linux Signal?

We all understand a red light means that we have to stop walking or driving. Similarly, in Linux and Unix systems, one can pass a signal to a running program or service to interact with it. For example, one could send a red traffic light sign to a program by simply issuing a

        SIGTERM
    

signal.

Just like with a red traffic light, people may choose to continue to walk or drive when the light is red. Whilst that may not be a safe idea for all involved, a

        SIGTERM
    

signal send to a process will do exactly that; the process/program may choose to ignore such a signal.

The basic Linux signals all have a number (1-30+). After a little while, a proficient Linux user will generally know one or more of these. For example, the

        SIGTERM
    

signal matches with number 15, and signal 9 (

        SIGKILL
    

) is likely the most the most known one as it allows one to forcefully terminate a process, unlike our

        SIGTERM
    

red light example.

Here we see the main screen of

        htop
    

(you can install this handy utility by typing

        sudo apt install htop
    

on Ubuntu/Mint, or

        sudo yum install htop
    

on RedHat/Centos/Fedora) with a number of termination and other signals (lower in the list; there are 37 in total) which can be sent to a process previously selected on the right. One can select a process by pressing the cursor up/down and then send a signal by using F9.

SIGKILL & SIGTERM

Whilst the name may sound a little sinister, the common Linux lingo for process termination is that one 'kills' a process. Generally speaking, we will only want to terminate a process with a

        -9
    

(

        SIGKILL
    

) signal if such a process/program is hanging. Note that whenever we speak of process or program, the words can be interchanged at will. Basically, a process is any running program (or service) that has been given a PID (a process identifier).

Let's look at an example of terminating a running background process by using a

        SIGKILL
    

signal to the running process. Note that as explained

        SIGKILL
    

is rather destructive and will terminate the process no matter what the process would like to do with the signal. A number of signals can be captured and redirected by the process, whereas others cannot.

Here we started a

        sleep 1800
    

in the background (using

        &
    

at the end of the command), which was started as the first (

        [1]
    

) background process with

        PID 574660
    

. We subsequently killed that background process using

        kill -9 574660
    

, where the

        -9
    

stands for

        SIGKILL
    

.

While the process is terminated immediately, we do not see the termination message (background process

        1
    

killed, i.e.,

        [1]+ Killed
    

) as the command prompt returns before the message is displayed, i.e., returning the command line was a faster operation then the process termination, or similar.

We check the process list by grepping for the PID

        ps -ef | grep 574660
    

. Whilst there is some output, the output shown is only for our running

        grep
    

command; the

        sleep
    

process has already been terminated.

Let's evaluate the same with

        SIGTERM
    

, i.e.

        kill -15 ${PID}
    

where

        ${PID}
    

is the process we want to terminate.

We had to press enter to trigger/show the termination message (as explained above). We can see that the program terminated correctly again. However, this time, while invisible for this particular example (read on!), internally inside the

        sleep
    

program code, things went a little different.

In this case (using

        -15
    

i.e.

        SIGTERM
    

to terminate the process), the

        sleep
    

process was notified and had the opportunity to internally handle the signal. It could subsequently respond by self-terminating, by ignoring the signal, or by any other action as developed into the code. We can also prove this to be true by checking the exit signal and/or output:

Here we started the process

        sleep 2000
    

twice, and then used another shell/terminal session to terminate the program. The first time, we used

        kill -9
    

and the second time we used

        kill -15
    

to stop the

        sleep
    

process.

We immediately notice how the output returns

        Killed
    

in the first (

        kill -9
    

action) instance. For the second attempt (using

        kill -15
    

), we see the output

        Terminated
    

instead; the program self-terminated. Subsequent to the respective terminations we also checked the exit signals, and found that the exit codes were different.

Why is this important? Consider larger programs; in this instance, we were just terminating a simple

        sleep
    

command. There was no data being handled, no traffic being sent back/forth, etc. But what would happen if we sent a

        kill -9
    

command to our database server (this would generally speaking require sudo/root-level privileges)?

It would trigger the database to go into crash recovery mode the next time it starts up because, as far as the database software knows, all that happened was "was there" followed by "nothing." In other words, it crashed. If we had instead issued a

        kill -15
    

command, the database software could have done a controlled shutdown, for example, by first blocking new users from connecting, then disconnecting/terminating existing users, then finish writing data, etc. before finally self-terminating.

Sending Linux Signals with Keyboard Sequences

Did you know that whenever you sent a

        CTRL+c
    

key sequence to a running program, for example in a terminal, that instead a

        SIGINT
    

is sent? Let's step back to our trusted

        sleep
    

command and test this:

Here we started

        sleep
    

again, and then pressed the keyboard combination

        CTRL+c
    

. The program terminated, or better was interrupted by the

        SIGINT
    

signal that was sent. We request the exit code and confirm that once again the exit code is different from the previous signals.

Note that this exit code, for sleep, will always be matched to the signal sent, though potentially not all signals may be covered. In other words, when using

        CTRL+c
    

at the command line the exit code will always be

        130
    

,

        137
    

when killed with

        kill -9
    

, and

        143
    

when

        kill -15
    

was used.

You can test exit codes for commands by querying the

        $?
    

variable, which holds the exit code of the previous command (as long as you have not commenced a new command). Knowing the exit code of a given command in a particular situation, and/or as the result of a particular signal sent to that command, helps when scripting solutions that handle other processes, etc. (which is the case for many shell scripts, especially when managing servers or automated environments).

Another often-used keyboard sequence is

        CTRL+z
    

. This will sent a

        SIGTSTP
    

signal, a

        suspend
    

signal which immediately places a process in suspension until (for example) a

        'fg'
    

command is issued for the same process which will bring it back to the foreground.

To learn more about process management, see Bash Process Termination Hacks.

Wrapping up

In this article, we looked at the most important Linux signals and how we may practically use them in a Linux or Unix environment. Knowing the basic Linux signals aids one with daily Linux use and management, for example, when a process is hanging and needs to be terminated with

        kill -9
    

. In a future article, we may look at capturing a signal using the

        trap
    

command from inside a Bash script, allowing one to define a custom procedure to be executed when such a signal is issued.

If you enjoyed reading this article, have a look at our Bash automation series starting at Bash Automation & Scripting Basics. In the third article in that series, we also discuss background process management, touched on earlier in this article.