Bash 'kill' Signals: Controlling Processes

1. Introduction to Signals

In Unix-like operating systems (including Linux and macOS, where Bash is commonly used), signals are a fundamental form of inter-process communication (IPC). They are software interrupts sent to a program to indicate that an important event has occurred.

The kill command is the primary tool used from the command line to send these signals to specified processes, most commonly to request termination or modification of the process state.

You can list available signals on your system using:

kill -l
# or for a more detailed system list
/bin/kill -L

There are typically 64 signals available, with the first 31 being standard signals and the rest being real-time signals. Most users interact with a smaller subset of common signals.

2. Common Kill Signals

While many signals exist, a few are used much more frequently for general process management.

Note: Whether a signal "Can Be Caught" indicates if a program can define a custom handler to intercept the signal and perform specific actions (like cleanup) or ignore it. Signals that cannot be caught (SIGKILL, SIGSTOP) always perform their default action.

3. Key Signal Details

Understanding the difference between the most common termination and control signals is crucial.

SIGTERM (15): The Polite Request

• This is the default signal sent by kill if none is specified.
• It's a graceful termination request.
• The receiving process can catch this signal.
• Well-behaved applications should catch SIGTERM to:
  • Save current work or state.
  • Close open files and network connections.
  • Release resources cleanly.
  • Terminate child processes if necessary.
• Best Practice: Always try SIGTERM first.

SIGKILL (9): The Forceful Command

• This signal forces the kernel to terminate the process immediately.
• It cannot be caught, blocked, or ignored by the process.
• No cleanup operations are performed by the application.
• Use Case: A last resort for processes that are unresponsive to SIGTERM or are malfunctioning severely.
• Warning: Using SIGKILL can lead to data loss or corruption if the process was in the middle of writing files or other critical operations.

SIGHUP (1): Hang Up / Reload Config

• Historically used to signal a hangup on a controlling terminal.
• Modern Use: Commonly used to signal daemon processes to reload their configuration files without fully restarting the service (e.g., web servers, logging services).
• Applications must be specifically programmed to handle SIGHUP for configuration reloading.

SIGSTOP (19) & SIGCONT (18): Pausing and Resuming

• SIGSTOP immediately pauses (suspends) a process.
• It cannot be caught by the process.
• The process remains in memory but does not get CPU time until resumed.
• SIGCONT is used to resume a process previously stopped by SIGSTOP (or SIGTSTP).
• SIGTSTP (20), triggered by Ctrl+Z, is similar to SIGSTOP but can be caught, allowing a program to potentially perform actions before suspending.

4. Using the kill Command

Syntax

The basic syntax is:

kill [options] <PID>...

Where <PID> is the Process ID. You can get PIDs using commands like ps, pgrep, or top/htop.

Specifying Signals

You can specify signals in three ways:

1. By Number: kill -9 <PID> (Sends SIGKILL)
2. By Name (with SIG prefix): kill -SIGTERM <PID>
3. By Name (without SIG prefix): kill -TERM <PID>

If no signal is specified, SIGTERM (15) is sent by default:

kill <PID> # Equivalent to kill -15 <PID> or kill -TERM <PID>

Bash kill vs. System kill

• The kill command built into Bash can also operate on job IDs (e.g., kill %1).
• The system command (/bin/kill) typically only accepts PIDs.

5. Best Practices for Terminating Processes

1. Start with SIGTERM: Always send kill <PID> (or kill -15 <PID>) first. Give the process a chance to shut down gracefully (allow a few seconds).
2. Verify Termination: Use ps or pgrep to check if the process has exited after sending SIGTERM.
3. Use SIGKILL as a Last Resort: If the process does not terminate after SIGTERM, then use kill -9 <PID> to force termination.
4. Permissions: Remember that regular users can only send signals to processes they own. The root user can send signals to any process.

6. Termination Flowchart

There are typically 64 signals available, with the first 31 being standard signals and the rest being real-time signals. Most users interact with a smaller subset of common signals.

2. Common Kill Signals

While many signals exist, a few are used much more frequently for general process management.

Note: Whether a signal "Can Be Caught" indicates if a program can define a custom handler to intercept the signal and perform specific actions (like cleanup) or ignore it. Signals that cannot be caught (SIGKILL, SIGSTOP) always perform their default action.

3. Key Signal Details

Understanding the difference between the most common termination and control signals is crucial.

SIGTERM (15): The Polite Request

• This is the default signal sent by kill if none is specified.
• It's a graceful termination request.
• The receiving process can catch this signal.
• Well-behaved applications should catch SIGTERM to:
  • Save current work or state.
  • Close open files and network connections.
  • Release resources cleanly.
  • Terminate child processes if necessary.
• Best Practice: Always try SIGTERM first.

SIGKILL (9): The Forceful Command

• This signal forces the kernel to terminate the process immediately.
• It cannot be caught, blocked, or ignored by the process.
• No cleanup operations are performed by the application.
• Use Case: A last resort for processes that are unresponsive to SIGTERM or are malfunctioning severely.
• Warning: Using SIGKILL can lead to data loss or corruption if the process was in the middle of writing files or other critical operations.

SIGHUP (1): Hang Up / Reload Config

• Historically used to signal a hangup on a controlling terminal.
• Modern Use: Commonly used to signal daemon processes to reload their configuration files without fully restarting the service (e.g., web servers, logging services).
• Applications must be specifically programmed to handle SIGHUP for configuration reloading.

SIGSTOP (19) & SIGCONT (18): Pausing and Resuming

• SIGSTOP immediately pauses (suspends) a process.
• It cannot be caught by the process.
• The process remains in memory but does not get CPU time until resumed.
• SIGCONT is used to resume a process previously stopped by SIGSTOP (or SIGTSTP).
• SIGTSTP (20), triggered by Ctrl+Z, is similar to SIGSTOP but can be caught, allowing a program to potentially perform actions before suspending.

4. Using the kill Command

Syntax

The basic syntax is:

kill [options] <PID>...

Where <PID> is the Process ID. You can get PIDs using commands like ps, pgrep, or top/htop.

Specifying Signals

You can specify signals in three ways:

1. By Number: kill -9 <PID> (Sends SIGKILL)
2. By Name (with SIG prefix): kill -SIGTERM <PID>
3. By Name (without SIG prefix): kill -TERM <PID>

If no signal is specified, SIGTERM (15) is sent by default:

kill <PID> # Equivalent to kill -15 <PID> or kill -TERM <PID>

Bash kill vs. System kill

• The kill command built into Bash can also operate on job IDs (e.g., kill %1).
• The system command (/bin/kill) typically only accepts PIDs.

5. Best Practices for Terminating Processes

1. Start with SIGTERM: Always send kill <PID> (or kill -15 <PID>) first. Give the process a chance to shut down gracefully (allow a few seconds).
2. Verify Termination: Use ps or pgrep to check if the process has exited after sending SIGTERM.
3. Use SIGKILL as a Last Resort: If the process does not terminate after SIGTERM, then use kill -9 <PID> to force termination.
4. Permissions: Remember that regular users can only send signals to processes they own. The root user can send signals to any process.