A signal is an asynchronous notification delivered to a process or a particular thread. Signals report events and request actions, but carry only limited information compared with data-oriented interprocess communication mechanisms.
Processes · Lesson 6
Signals
Learn how Linux generates, blocks, delivers, and handles signals for process control and event notification.
Where Signals Come From
Signals can originate in several places:
- A terminal can generate
SIGINTforCtrl-CorSIGTSTPforCtrl-Zand direct it to the foreground process group. - The kernel can generate a synchronous signal such as
SIGSEGVwhen a thread makes an invalid memory reference. - A process can send an authorized signal to another process or process group.
- Timers, child-state changes, and terminal hangups can generate other signals.
The sender must have appropriate permission, normally based on credentials or capabilities. Signals are therefore a kernel-mediated control interface, not unrestricted messages between arbitrary users.
Which signal does a terminal normally generate for Ctrl-C?
Dispositions and Default Actions
Most signals have a process-wide disposition that selects one of three responses:
- perform the signal's defined default action
- ignore the signal
- invoke a user-installed handler
Default actions differ: a signal may terminate, terminate and create a core dump, stop, continue, or be ignored. Catching SIGTERM can let a program begin an orderly shutdown, but a handler must follow strict async-signal-safety rules and the program can still delay or decline to exit.
Signal names are more portable and readable than numbers. Although common Linux architectures use SIGTERM as 15, do not assume all signal numbers except those guaranteed by the relevant standard are identical everywhere. Use kill -l to inspect the local mapping.
Why can a process respond gracefully to SIGTERM?
Blocking and Pending Signals
Threads have signal masks that can temporarily block delivery of selected signals. A generated blocked signal remains pending until it can be delivered, subject to the rules for standard and real-time signals. Standard signals of the same type can coalesce rather than queue once per occurrence.
In a multithreaded process, a process-directed signal can be delivered to an eligible thread that does not block it; a thread-directed signal targets the specified thread. Correct signal design therefore requires more than checking whether “the process blocked it.”
What normally happens when a blockable signal is generated while its target blocks it?
Signals That Cannot Be Handled
SIGKILL terminates a process and SIGSTOP stops it. Neither signal can be caught, ignored, or blocked. This guarantees that the kernel retains ultimate control, but it also means SIGKILL provides no opportunity for application-level cleanup.
Even SIGKILL may not make a task disappear instantly from an observer's perspective. A task can be waiting in an uninterruptible kernel operation, and after termination its parent still must reap its status.
Which pair cannot be caught, ignored, or blocked?
Lesson complete
You finished Signals
You can now explain the major stages and constraints of Linux signal handling.
Identify terminal, kernel, and process-generated signals.
Distinguish default actions, ignored signals, and handlers.
Relate blocking to pending delivery and thread masks.
Remember that
SIGKILLandSIGSTOPcannot be handled or blocked.
Keep your learning progress
Create a free account to save this lesson and continue learning on any device.
Create a free account