Signal Interception for Debugging

In this lesson, you will learn how to use signal injection to force a stuck process to reveal its internal state without killing it.

The Problem: The "Frozen" Process

Sometimes, a process becomes unresponsive—it consumes CPU but produces no output. Because the process is still running, you cannot look at its exit code or log files from after the fact. To debug this "live" state, you need to pause the process, inspect its memory, and then resume it, or force it to dump its current stack trace.

Using Signals for Inspection

In Linux, you can "inject" signals into a process to change its behavior temporarily. The most common signal for debugging a frozen process is SIGQUIT (Signal 3). Unlike SIGTERM or SIGKILL, which request or force termination, SIGQUIT is traditionally used to tell a process to stop what it is doing, dump its current memory state to a file (a "core dump"), and then exit.

If you don't want the process to die, you can use SIGSTOP (Signal 19) and SIGCONT (Signal 18).

Practical Workflow

If you have a process ID (PID) of 1234 that is stuck, you can attempt to capture its current execution state:

1. Pause the process:

   kill -SIGSTOP 1234
   

   The process is now frozen in time. You can use tools like gdb (GNU Debugger) to attach to it:

   gdb -p 1234
   

   Inside gdb, you can run bt (backtrace) to see exactly which function the program is currently stuck in.

2. Resume the process: Once you have gathered the data, you can let it continue:

   kill -SIGCONT 1234
   

By using SIGSTOP to halt the process, you prevent the state from changing while you attach a debugger. This allows you to perform post-mortem style analysis on a process that is technically still alive. This is far more effective than killing the process, which would destroy the evidence of why it was stuck in the first place.

Key Takeaway: Use SIGSTOP to pause a stuck process for live inspection with a debugger, and SIGQUIT to force an immediate core dump for later analysis.