Signals

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.

Where Signals Come From

Signals can originate in several places:

• A terminal can generate SIGINT for Ctrl-C or SIGTSTP for Ctrl-Z and direct it to the foreground process group.
• The kernel can generate a synchronous signal such as SIGSEGV when 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.

CheckWhich signal does a terminal normally generate for Ctrl-C?

SIGTSTP SIGCONT SIGINT

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.

CheckWhy can a process respond gracefully to SIGTERM?

It can install a handler for that signal. The kernel always saves every open document automatically. SIGTERM cannot cause termination by default.

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.”

CheckWhat normally happens when a blockable signal is generated while its target blocks it?

It remains pending until delivery becomes possible. It is converted automatically into SIGKILL. It changes the target process's user ID.

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.

CheckWhich pair cannot be caught, ignored, or blocked?

SIGKILL and SIGSTOP SIGINT and SIGTERM SIGHUP and SIGCONT

Summary

You can now explain the major stages and constraints of Linux signal handling.

1. Identify terminal, kernel, and process-generated signals.
2. Distinguish default actions, ignored signals, and handlers.
3. Relate blocking to pending delivery and thread masks.
4. Remember that SIGKILL and SIGSTOP cannot be handled or blocked.