Software interrupts on Linux and Unix systems are done through signals. There are many different Linux signals, but some are highlighted and it is essential to understand and know them: SIGINT, SIGTERM y SIGKILL. This is how they work.
What is a Linux signal?
We all understand that a red light means we have to stop walking or driving. Equivalently, on Linux and Unix systems, a signal can be passed to a running program or service to interact with it. As an example, one could send a red light signal to a program simply by broadcasting a SIGTERM sign.
Just like with a red light, people may choose to keep walking or driving when the light is red. Although it may not be a safe idea for everyone involved, a SIGTERM signaling a procedure will do exactly that; The procedure / program can choose to ignore said signal.
All basic Linux signals have a number (1-30 +). After a while, a generally proficient Linux user will know one or more of these. As an example, the SIGTERM the signal matches the number 15 and the signal 9 (SIGKILL) is probably the best known, since it makes it possible to forcibly terminate a procedure, 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 in Ubuntu / Mint, O sudo yum install htop in RedHat / Centos / Fedora) with a series of termination signals and other (further down the list; there are 37 total) that can be sent to a previously selected procedure on the right. One can choose a procedure by pressing the cursor up / down and then send a signal using F9.
SIGKILL & SIGTERM
Although the name may sound a bit sinister, the common Linux jargon for process termination is that one “shrub” A procedure. In general terms, we will only want to end a procedure with a -9 (SIGKILL) signal if said procedure / program is blocked. Keep in mind that whenever we talk about procedure or program, words can be exchanged at will. Simply, a procedure is any program (or service) running that has been given a PID (a procedure identifier).
Let's see an example of how to end a running background procedure via a SIGKILL signal to the running procedure. Note that, as explained SIGKILL it is quite destructive and will terminate the procedure no matter what the procedure wants to do with the signal. The procedure can capture and redirect multiple signals, while others don't.
Here we start a sleep 1800 in background (using & at the end of the command), that started as the first ([1]) background procedure with PID 574660. Subsequently, we kill that background procedure using kill -9 574660, where he -9 It represents SIGKILL.
Although the procedure ends immediately, we don't see the completion message (background procedure 1 murdered, In other words, [1]+ Killed) when the command prompt returns before the message is displayed, In other words, returning the command line was a faster operation than the completion of the procedure or equivalent.
We verify the list of processes by grepping for the PID ps -ef | grep 574660. Although there may be some way out, the output shown is for our execution only grep command; the sleep The procedure has already finished.
Let's evaluate the same with SIGTERM, In other words kill -15 ${PID} where ${PID} is the procedure we want to finish.
We had to press enter to activate / show completion message (as previously explained). We can see that the program ended correctly again. Despite this, this time, even though invisible for this particular example (keep reading!), Internally within the sleep program code, things were a little different.
For this case (using -15 In other words SIGTERM to finish the procedure), the sleep The procedure was notified and had the possibility to handle the signal internally. Subsequently, could respond by self-terminating, ignoring the signal or through any other action developed in the code. Furthermore we can prove that this is true by checking the output signal and / or the exit:
Here we start the procedure sleep 2000 twice, and then used another shell session / terminal to end the program. The first time we use kill -9 and the second time we use kill -15 to stop the sleep process.
We immediately notice how the exit returns. Killed in the first (kill -9 action) instance. For the second try (using kill -15), we see the exit Terminated instead of; the program ended automatically. After the respective terminations, we also checked the output signals and found that the output codes were different.
Why is this important? Consider larger programs; in this circumstance, we were just finishing a simple sleep command. No data was handled, no traffic was sent back and forth, etc. But, What if we send a kill -9 command to our database server (this, usually, would require root level privileges / sudo)?
I would wake the database to go into crash recovery mode the next time it is started because, as far as the database software knows, everything that happened was “was there” followed by “any”. In other words, it crashed. If instead we had issued a kill -15 , the database software could have performed a controlled shutdown, as an example, first blocking the connection of new users, then disconnecting / terminating existing users, after finishing writing data, etc. before in short auto-terminate.
Sending Linux signals with keyboard sequences
Did you know that every time you sent a CTRL+c key sequence to a running program, as an example in a terminal, that instead a SIGINT is sent? Let's go back to our trust sleep command and try this:
Here we start sleep again, and then hit the keyboard combination CTRL+c. The program ended, or better was interrupted for him SIGINT signal that was sent. We request the exit code and confirm that once again the exit code is different from the previous signals.
Please note that this exit code, for sleeping, will always match the signal sent, even though not all signals may be covered. In other words, when using CTRL+c on the command line, the exit code will always be 130, 137 when killed with kill -9, and 143 when kill -15 it was used.
You can test the command exit codes by referring to the $? variable, which contains the exit code of the above command (as long as a new command has not started). Know the exit code of a given command in a particular situation, and / or as a consequence of a particular signal sent to that command, helps when scripting solutions that handle other processes, etc. (which is the case with many shell scripts, especially when managing servers or automated environments).
Another frequently used keyboard sequence is CTRL+z. This will send a SIGTSTP sign, a suspend signal that immediately puts a procedure on hold until (as an example) a 'fg' The command is issued for the same procedure that will bring it back to the foreground.
For more information on process management, consulte Bash Process Termination Hacks.
Ending
In this post, We discuss the most important Linux signals and how we can practically use them in a Linux or Unix environment. Knowing the basic Linux cues helps one with the daily use and management of Linux, as an example, when a procedure hangs and must be terminated with kill -9. In a future post, we can consider capturing a signal using the trap command from inside a bash script, which makes it possible to establish a custom procedure that will be executed when said signal is emitted.
If you enjoyed reading this post, take a look at our bash automation series starting at bash automation & Scripting Basics. In the third post of that series, we also analyze the administration of processes in the background, which was previously mentioned in this post.
