What Are Signals in an Operating System?
Learn what signals are — asynchronous kernel notifications, handlers, and uncatchable signals — with OS interview questions answered.
Expected Interview Answer
A signal is a limited, asynchronous notification the kernel delivers to a process to inform it of an event — such as a fault, a user interrupt, a timer expiry, or another process’s request — interrupting the process’s normal control flow to run a handler or apply a default action.
Each signal has a small integer number (SIGINT, SIGKILL, SIGSEGV, SIGCHLD, and so on) and the kernel maintains a pending set and a per-process disposition table describing what to do when each one arrives: run a registered handler, ignore it, or apply the default action such as terminate, dump core, or stop. Signals can originate from hardware (an illegal instruction raises SIGILL), the kernel (a child exiting raises SIGCHLD to its parent), or another process via a call such as kill(). Because delivery can happen at almost any point in execution, handlers must be careful to only call async-signal-safe functions, and some signals — most notably SIGKILL and SIGSTOP — cannot be caught, blocked, or ignored, guaranteeing the OS always retains a way to terminate or pause a process. Signals carry no data payload beyond their number (real-time signals add limited payload), which is what distinguishes them from richer IPC channels like pipes or message queues.
- Delivers asynchronous, out-of-band notifications without polling
- Provides an uncatchable path (SIGKILL/SIGSTOP) to control any process
- Lets processes install custom handlers for graceful cleanup
- Underpins job control, crash reporting, and child-exit notification
AI Mentor Explanation
A signal is like the umpire blowing a whistle to stop play instantly for an injury, regardless of what over or delivery is in progress. Each whistle pattern maps to a known meaning the players have agreed on in advance — one pattern means pause, another means the match is abandoned entirely and cannot be waved off by any player. A team can prepare a specific routine for the pause whistle, but the abandonment whistle always ends the match no matter what routine anyone tries to run.
Step-by-Step Explanation
Step 1
Event occurs
Hardware fault, kernel event, timer expiry, or another process calling kill() generates a signal number.
Step 2
Kernel marks pending
The kernel sets the signal as pending in the target process's signal mask, to be delivered at the next opportunity.
Step 3
Disposition check
The kernel checks the process's disposition table: a registered handler, SIG_IGN, or the default action.
Step 4
Delivery
A registered handler runs (interrupting normal flow), or the default action (terminate, stop, ignore, core-dump) is applied.
What Interviewer Expects
- Clear definition tying signals to asynchronous kernel notification
- Knowledge that SIGKILL/SIGSTOP cannot be caught or ignored
- Awareness of async-signal-safety constraints inside handlers
- A concrete example of a signal origin (hardware, kernel, or another process)
Common Mistakes
- Claiming every signal can be caught with a custom handler
- Treating signals as a reliable, high-bandwidth data channel
- Calling unsafe library functions like malloc() inside a signal handler
- Confusing signal delivery with synchronous system-call return values
Best Answer (HR Friendly)
“Signals are the operating system’s way of tapping a process on the shoulder to say something urgent just happened, like a crash, a timer running out, or another program asking it to stop. A process can choose to react in its own way to most of these taps, but a couple of them, like the forced kill, can never be ignored, so the system always has a guaranteed way to stop something.”
Code Example
#include <signal.h>
#include <unistd.h>
#include <stdlib.h>
volatile sig_atomic_t shutdown_requested = 0;
void handle_sigterm(int signum) {
/* only async-signal-safe operations belong here */
shutdown_requested = 1;
}
int main(void) {
struct sigaction sa;
sa.sa_handler = handle_sigterm;
sigemptyset(&sa.sa_mask);
sa.sa_flags = 0;
sigaction(SIGTERM, &sa, NULL); /* SIGKILL could not be caught this way */
while (!shutdown_requested) {
/* main work loop */
}
/* safe cleanup happens here, outside the handler */
return 0;
}Follow-up Questions
- Why can SIGKILL and SIGSTOP never be caught or blocked?
- What does async-signal-safe mean, and why does it matter inside a handler?
- How does sigprocmask() differ from installing a signal handler?
- How does a real-time signal differ from a standard POSIX signal?
MCQ Practice
1. Which pair of signals can never be caught, blocked, or ignored?
SIGKILL and SIGSTOP are enforced directly by the kernel and bypass any process-level disposition, guaranteeing the OS can always terminate or pause a process.
2. What should a well-written signal handler avoid calling?
Because a handler can interrupt code at any point, calling non-reentrant functions like malloc() risks corrupting state the interrupted code was mid-way through using.
3. What triggers SIGCHLD being sent to a parent process?
The kernel raises SIGCHLD to notify a parent that one of its child processes has changed state, typically by exiting.
Flash Cards
What is a signal? — An asynchronous kernel notification of an event, identified by a small integer number, delivered to a process.
Which signals cannot be caught? — SIGKILL and SIGSTOP — the kernel enforces them unconditionally.
What must signal handlers avoid? — Calling non-reentrant, async-signal-unsafe functions such as malloc() or printf().
Where can a signal originate? — Hardware faults, kernel events, timers, or another process calling kill().