Signaling Processes with `kill` and `pkill`

1. Beyond "Killing": Understanding Signals

First, let's clarify the terminology. While the command is called kill, it doesn't always mean immediate termination. In Linux, "killing" a process really means sending it a signal. A signal is a standardized message the operating system sends to a program to tell it that a specific event has occurred. The program can then react accordingly.

There are many signals, but for now, we'll focus on the three most important ones:

• SIGTERM (Signal 15): The "terminate" signal. This is a polite request asking a process to shut down. It's the default signal sent by the kill command. A well-behaved program will catch this signal, perform necessary cleanup operations (like saving files), and then exit gracefully.
• SIGKILL (Signal 9): The "kill" signal. This is not a request; it's a direct order to the operating system kernel to terminate the process immediately. The process cannot ignore this signal. This is your tool of last resort for a frozen application, as it prevents any cleanup and can lead to data corruption.
• SIGHUP (Signal 1): The "hang up" signal. Historically, this was used when a user's terminal connection was lost (hung up). Today, many system services and daemons are programmed to interpret this signal as a command to reload their configuration files without restarting the entire service.

The diagram below gives a good overview of how signals fit into the lifecycle of a process. Notice how signals like SIGTERM and SIGKILL are used to transition a process to the "Killed" state.

2. The Theory and the Tools in Action

To get a solid grasp of these concepts and the tools we'll be using, let's watch a video that explains and demonstrates them clearly.

3. Practice Time: Wielding Your "Katana"

Now it's time to put this into practice. We'll use the processes you created in the last lesson to simulate real-world scenarios.

First, make sure your test processes are running. If you've rebooted since the last lesson, open a terminal and start them again:

# Create a simple background worker script
echo 'while true; do echo "Worker is running..."; sleep 5; done' > worker.sh
chmod +x worker.sh
./worker.sh &




# Create a process that hogs CPU
yes > /dev/null &

You now have a well-behaved worker.sh script and an unruly yes process running. You can verify this with htop.

Scenario 1: The Polite Shutdown (SIGTERM)

Your worker.sh script is a well-behaved background task. Let's ask it to shut down gracefully.

1. Find the PID: Use pgrep to get the Process ID of your script.

   pgrep worker.sh
   

   This will return a number. Let's say it's 12345.

2. Send the SIGTERM signal: Use the kill command with the PID you just found. Since SIGTERM is the default, you don't need to specify it.

   kill 12345 
   

   After you press Enter, you should see a message on your terminal like "Terminated". This is the shell telling you that the background job has ended because it received the SIGTERM signal.

3. Verify: Check that the process is truly gone.

   pgrep worker.sh
   

   This command should return no output.

Scenario 2: The Force Quit (SIGKILL)

The yes process is simulating a frozen application. It's stuck in a tight loop and won't respond to polite requests.

1. Find the PID:

   pgrep yes
   

   Let's say the PID is 54321.

2. Attempt a polite shutdown:

   kill 54321
   

   Wait a few seconds. The process is likely still running (you can check htop in another terminal). It's ignoring SIGTERM.

3. Send the SIGKILL signal: Now, we escalate. You can specify the signal by its number (-9) or its name (-SIGKILL). The number is more common.

   kill -9 54321
   

   You should immediately see a "Killed" message. This is a much more forceful termination handled by the kernel itself.

Scenario 3: The Name Game (pkill)

Imagine a service has gone haywire and spawned dozens of identical processes. Finding and killing each PID would be tedious. This is where pkill shines.

1. Create some processes: Let's start a few sleep commands in the background.

   sleep 1000 &
   sleep 1000 &
   sleep 1000 &
   

2. Terminate by name: Now, use pkill to terminate all processes whose name matches "sleep".

   pkill sleep
   

   You will see "Terminated" messages for all the sleep jobs you started. This is far more efficient than finding and killing three separate PIDs. As the video showed, pkill is also great when you only know part of a process name (like pkill firefo for firefox-esr).

4. Consolidating Your Knowledge

You've done the practical work. Now, let's review the concepts and best practices. This will help solidify the "why" behind your actions, which is crucial for interviews.

To give you a quick visual summary of the commands, here is a helpful cheat sheet.

Conclusion

Excellent work. You've moved from a passive observer to an active administrator who can manage running processes. You now have the fundamental skills to handle unresponsive applications and misbehaving services—a core responsibility in any data center or sysadmin role.

Key Takeaways:

• Signals are messages: "Killing" a process is about sending it a signal. The most common are SIGTERM (15) for a graceful shutdown and SIGKILL (9) for a forced termination.
• Be polite first: Always start with a standard kill command (which sends SIGTERM). Only escalate to kill -9 if the process is unresponsive.
• Use the right tool for the job:
  • kill <PID> targets one specific process.
  • pkill <name> targets one or more processes by name, even a partial name.
  • killall <exact_name> targets all processes matching an exact name.

In our next lesson, we will continue exploring the process lifecycle. You've learned to monitor and terminate processes. Next, you'll learn how to properly run and manage processes in the background using tools like &, nohup, jobs, fg, and bg, ensuring your important tasks keep running even after you log out.