Home Learn Linux The ABCs of Linux Signals: SIGINT, SIGTERM, and SIGKILL explained

The ABCs of Linux Signals: SIGINT, SIGTERM, and SIGKILL explained

This guide will explain what these signals are, their differences, and how to use them. By the end, you'll have a solid understanding of Linux signals, enhancing your ability to manage processes and troubleshoot issues.

by Divya Kiran Kumar
how sigint, sigterm, and sigkill control linux processes

One of the many features that make Linux such a fascinating and effective tool is its ability to manage processes efficiently. In the realm of process management, few things are as fundamental or as critical as signals. Today, I’m going to delve into the intricacies of three specific Linux signals – SIGINT, SIGTERM, and SIGKILL. These signals are critical in stopping or terminating processes, and knowing how to use them properly can significantly enhance your ability to manage your system.

The concept of signals in Linux

Before we dive into the specifics of SIGINT, SIGTERM, and SIGKILL, let’s briefly discuss what signals are in the Linux universe. Think of signals as a way of communication between different processes within the operating system. They can originate from a user, a process, or the kernel itself and are used to notify a process that a particular event has occurred. Signals provide a method to handle asynchronous events and are an essential part of interprocess communication (IPC) in Unix-like systems.

SIGINT: The gentle nudge

SIGINT, or Signal Interrupt, is perhaps the most commonly encountered signal for many users. This signal is typically associated with the CTRL+C command you often use in your terminal to stop a running process. The primary purpose of SIGINT is to notify a process that the user has requested an interruption.

Take this example: Imagine you have executed a command that is taking longer than you anticipated, and you want to stop it. You simply hit CTRL+C, and the system sends a SIGINT signal to the process. Let’s see this in action:

$ sleep 100

Here, the ‘sleep 100’ command puts the system to sleep for 100 seconds. However, I realize I do not want to wait that long and press CTRL+C to stop the process. The ‘^C’ symbolizes the SIGINT signal being sent to the ‘sleep’ process.

  • SIGINT Pro Tip: SIGINT can be caught, ignored, or handled by the process. This flexibility means that if a process has a specific task to perform before it stops (like saving a file or releasing resources), it can catch the SIGINT signal, perform the task, and then terminate.

SIGTERM: The polite request

SIGTERM, or Signal Terminate, is the default signal sent to a process to kill it. SIGTERM is more forceful than SIGINT but still gives a process the opportunity to perform clean-up tasks before it ends. It allows the process to catch the signal and manage its termination elegantly – saving data or finishing essential tasks.

Here’s a practical example: Let’s say a process with a Process ID (PID) of 1234 is running, and you want to stop it.

$ kill 1234

The kill command, without any specified signal, sends a SIGTERM signal to the process. If the process can catch this signal and has defined a clean exit routine, it will execute that before exiting.

If you are wondering how to find the PID in the above example, please see our detailed article on How to find PID and PPID in Linux.

  • SIGTERM Pro Tip: SIGTERM respects the process’s right to clean up before terminating, making it the safest and most polite way to request a process termination. It’s my go-to signal when I need to stop a process without risking data corruption or other complications.

SIGKILL: The last resort

Now, what if a process does not respond to the SIGTERM signal, or is stuck in an endless loop and not releasing the resources? This is where SIGKILL comes in. SIGKILL, as the name suggests, kills the process immediately. The system does not give the process any chance to clean up or free up resources.

Let’s use the same example as before, but this time, imagine the process with PID 1234 is not responding to SIGTERM.

$ kill -9 1234

The ‘-9’ flag tells the ‘kill’ command to send a SIGKILL signal. The process is terminated instantly, regardless of what state it was in.

  • SIGKILL Pro Tip: While SIGKILL is very effective, I always recommend using it as a last resort. SIGKILL does not allow the process to close properly, which can lead to resource leaks, data loss, or other problems.

Understanding the differences: SIGINT, SIGTERM, and SIGKILL

One aspect I particularly love about Linux signals is that they follow the principle of escalation. SIGINT is a gentle nudge asking the process to stop. If that fails, SIGTERM is a more forceful, but still polite request for the process to terminate. Finally, if all else fails, SIGKILL terminates the process with no questions asked.

However, my inclination towards being systematic and respectful of processes’ right to clean up makes me a big fan of SIGTERM. While it’s more forceful than SIGINT, it still provides the process with a chance to tidy up before shutting down.

Conversely, SIGKILL, with its instantaneous and forcible termination, is my least favorite. It reminds me of a reckless bulldozer bringing down a building without checking if anyone is still inside. Yes, it gets the job done, but at the cost of potentially losing valuable data and causing other problems. This is not to say that SIGKILL doesn’t have its place; when a process is unresponsive and tying up resources, SIGKILL is often the only option. Just remember to use it judiciously!

My tips for organizational usage

My experience as a Linux system administrator has taught me a few things. SIGINT is a great first step in trying to stop a process because it gives it a chance to stop gracefully. But in an enterprise environment, where applications often run as daemons (background processes), SIGINT often proves ineffective because it is not designed to be sent to daemons.

That’s why I find SIGTERM to be the most practical signal in an organizational setting. It’s forceful enough to stop most processes but still gives them a chance to clean up and exit gracefully.

However, there are always those stubborn processes that will not stop even when they receive a SIGTERM signal. These are the ones that necessitate the use of SIGKILL. While I don’t like the brute force approach of SIGKILL, sometimes it is the only option to quickly free up resources and ensure the smooth operation of other services. It’s like the emergency break glass – you don’t want to use it unless you absolutely have to.

Ultimately, understanding and using Linux signals effectively is critical to managing an organization’s IT infrastructure. It’s not just about knowing what each signal does, but also understanding when and how to use them for maximum effect.

Wrapping up

Understanding Linux signals is a crucial aspect of managing your system effectively. SIGINT, SIGTERM, and SIGKILL, each with its unique characteristics, provide you with the power to control processes, ensuring smooth operation of your system. However, with great power comes great responsibility. It’s important to know when and how to use each signal to avoid unnecessary complications. Happy signaling!

You may also like

Leave a Comment


FOSS Linux is a leading resource for Linux enthusiasts and professionals alike. With a focus on providing the best Linux tutorials, open-source apps, news, and reviews, FOSS Linux is the go-to source for all things Linux. Whether you’re a beginner or an experienced user, FOSS Linux has something for everyone.

Follow Us


©2016-2023 FOSS LINUX