Linux Signals — Process Communication and Control¶

Linux processes communicate with each other and with the operating system using signals. A signal is a software interrupt that notifies a process that an event has occurred. Signals are used to terminate, pause, resume, reload, or interrupt running processes. Understanding signals is essential for Linux administrators, DevOps engineers, Cloud Architects, and Site Reliability Engineers (SREs).

Learning Path¶

Linux Mastery → Module 6: Process Management → Lesson 8

Difficulty: Beginner → Intermediate

Reading Time: 60 Minutes

Course Progress

Course: Linux Mastery

Module: Process Management

Lesson: 8 of 10

What You'll Learn¶

After completing this lesson, you'll be able to:

Understand Linux signals
Learn how processes communicate
Identify common signals
Send signals to processes
Understand signal handling
Use signals safely
Troubleshoot applications using signals
Apply signals in production environments

Prerequisites¶

Complete:

Module 1 – Linux Fundamentals
Module 2 – Linux Command Line Essentials
Module 3 – Text Processing
Module 4 – File Management and Permissions
Module 5 – Users and Groups
Module 6 Lessons 1–7

Why Learn Signals?¶

Imagine a production server where:

An application stops responding.
A web server needs to reload its configuration.
A backup process must be paused.
A database must shut down gracefully.

How does Linux communicate these requests?

The answer is Signals.

What is a Signal?¶

A signal is a software notification sent to a process.

It tells the process that something has happened or that it should perform a specific action.

Examples include:

Stop running
Pause execution
Resume execution
Reload configuration
Interrupt execution

Signal Communication¶

Administrator
       │
       ▼
kill Command
       │
       ▼
Linux Kernel
       │
       ▼
Target Process
       │
       ▼
Process Handles Signal

The kernel delivers the signal, and the process reacts according to the signal type.

Signal Numbers and Names¶

Signals have both:

A number
A name

Example:

15

↓

SIGTERM

Both commands are equivalent:

kill -15 PID

kill -SIGTERM PID

List Available Signals¶

Display all supported signals.

kill -l

Example:

HUP

INT

QUIT

KILL

TERM

STOP

CONT

Most Common Signals¶

Signal	Number	Purpose
SIGHUP	1	Reload configuration or notify a process of terminal disconnection (behavior depends on the application)
SIGINT	2	Interrupt process (`Ctrl + C`)
SIGQUIT	3	Quit and generate a core dump
SIGKILL	9	Force immediate termination
SIGTERM	15	Graceful termination
SIGSTOP	19	Pause a process
SIGCONT	18	Resume a paused process

SIGTERM¶

Gracefully terminate a process.

kill PID

or

kill -15 PID

The process can:

Save data
Close files
Release resources

This is the recommended method for stopping applications.

SIGKILL¶

Immediately terminate a process.

kill -9 PID

The kernel stops the process immediately.

The process cannot:

Save data
Close files
Perform cleanup

Use only when necessary.

SIGINT¶

Generated by:

Ctrl + C

Example:

python app.py

Press:

Ctrl + C

The application receives:

SIGINT

SIGSTOP¶

Pause a process.

kill -STOP PID

The process stops execution but remains in memory.

SIGCONT¶

Resume a paused process.

kill -CONT PID

The process continues execution from where it stopped.

SIGHUP¶

Many server applications interpret SIGHUP as a request to reload their configuration without restarting.

Example:

kill -HUP PID

Common use cases include:

Reloading web server configuration
Refreshing logging configuration
Reopening log files after rotation

Note

The exact behavior depends on how the application handles SIGHUP.

Signal Handling¶

Applications can choose to:

Handle a signal
Ignore certain signals
Perform cleanup before exiting

However:

SIGKILL

SIGSTOP

cannot be caught, blocked, or ignored by user-space applications.

Sending Signals¶

Graceful stop.

kill PID

Force stop.

kill -9 PID

Pause.

kill -STOP PID

Resume.

kill -CONT PID

Reload configuration.

kill -HUP PID

Common Commands¶

Display signals.

kill -l

Graceful termination.

kill PID

Force termination.

kill -9 PID

Pause.

kill -STOP PID

Resume.

kill -CONT PID

Real Production Examples¶

Reload NGINX configuration.

kill -HUP PID

Terminate a hung Java application.

kill -9 PID

Pause a long-running batch process.

kill -STOP PID

Resume processing.

kill -CONT PID

Production Perspective¶

Signals are widely used for:

Service management
Configuration reloads
Process termination
Application maintenance
Automation
Incident response
Deployment workflows

Many Linux services respond to signals without requiring a full restart.

Hands-on Lab¶

Task 1¶

Start a process.

sleep 600 &

Task 2¶

Find its PID.

ps -ef | grep sleep

Task 3¶

Pause the process.

kill -STOP PID

Verify:

ps -o pid,state,comm

Observe the process state.

Task 4¶

Resume the process.

kill -CONT PID

Task 5¶

Terminate gracefully.

kill PID

Task 6¶

Start another process.

sleep 600 &

Task 7¶

Force termination.

kill -9 PID

Task 8¶

Display available signals.

kill -l

Command Deep Dive¶

Command	Purpose	Production Example
`kill -l`	List signals	Signal reference
`kill PID`	Send SIGTERM	Graceful shutdown
`kill -9 PID`	Send SIGKILL	Force termination
`kill -STOP PID`	Pause a process	Maintenance
`kill -CONT PID`	Resume a process	Continue execution
`kill -HUP PID`	Reload configuration	Web servers

Production Troubleshooting Scenario¶

Scenario

An NGINX server receives an updated configuration.

Instead of restarting the service and interrupting client connections, the administrator reloads the configuration.

kill -HUP <nginx-master-pid>

Result:

Configuration is reloaded.
Existing connections continue.
Downtime is minimized.

This demonstrates why understanding signals is important for production operations.

Best Practices¶

Use SIGTERM before SIGKILL.
Verify the PID before sending signals.
Use SIGHUP only if the application supports configuration reloads.
Pause processes with SIGSTOP only when necessary.
Understand how critical applications respond to signals before using them in production.

Common Mistakes¶

❌ Using SIGKILL as the first option.

✅ Always try graceful termination first.

❌ Assuming every application reloads its configuration with SIGHUP.

✅ Behavior depends on the application's implementation.

❌ Sending signals to the wrong process.

✅ Always verify the PID and process name.

Interview Questions¶

Beginner¶

What is a Linux signal?
Which signal is sent by the kill command by default?
What does Ctrl + C generate?
Which command lists all available signals?

Intermediate¶

What is the difference between SIGTERM and SIGKILL?
What is the purpose of SIGSTOP and SIGCONT?
Why can't SIGKILL be ignored?
When is SIGHUP commonly used?

Architect Level¶

How would you reload a production web server without restarting it?
Why should graceful termination always be preferred?
How do Linux signals support zero-downtime operations?

Summary¶

In this lesson, you learned:

Linux signals
Process communication
Common signals
Signal handling
Process control
Configuration reloads
Production best practices

Signals are a fundamental mechanism for communication between the Linux kernel, administrators, and running processes. They provide a flexible and efficient way to control application behavior without directly interacting with process internals.

Key Takeaways¶

Signals are software interrupts sent to processes.
SIGTERM is the preferred method for graceful termination.
SIGKILL immediately terminates a process and should be used only when necessary.
SIGSTOP pauses a process, while SIGCONT resumes it.
Many applications use SIGHUP to reload configuration.
Understanding signals is essential for Linux administration and production operations.

What's Next?¶

systemd — Managing Services and System Initialization in Linux

You'll explore:

What systemd is
The boot process
Units and targets
Managing services
Viewing system status
Boot-time service management
Enterprise system administration

systemd is the default init system on most modern Linux distributions and is responsible for managing services, system startup, and background processes.