signals

Overview

Signals are how Linux tells a process to do something — pause, resume, reload, or terminate. Sending signals is the primary way to control running processes. This lesson explains signals and the common ones you will use.

Learning objectives

• Define signals and how they are sent.
• Identify common signals and their effects.
• Use signals to manage processes responsibly.

Core concept

A signal is an asynchronous notification delivered to a process, instructing it to take some action. Signals are sent with the kill command (despite the name, it sends any signal, not only termination) by PID. Common signals:

• SIGTERM (15) — polite request to terminate; the default; lets the process clean up.
• SIGKILL (9) — forceful, immediate termination; cannot be caught or ignored; no cleanup.
• SIGINT (2) — interrupt, sent by pressing Ctrl+C.
• SIGHUP (1) — hang-up; often used to tell services to reload configuration.
• SIGSTOP / SIGCONT — pause and resume a process.

How it works

kill <PID> sends SIGTERM by default, asking the process to shut down gracefully; the process can catch it, finish work, and exit cleanly. If it does not respond, kill -9 <PID> (SIGKILL) forces immediate termination — but because it allows no cleanup, it can leave temporary files or inconsistent state and should be a last resort. Many services treat SIGHUP as "reload your config" without a full restart. Some signals (SIGKILL, SIGSTOP) cannot be intercepted by the process.

Practical example

$ kill 1540            # SIGTERM: ask process 1540 to terminate gracefully
$ kill -HUP 900        # SIGHUP: tell the service (PID 900) to reload its config
$ kill -9 1540         # SIGKILL: force-terminate 1540 (last resort)

The first requests a clean shutdown; the second reloads a service's configuration without restarting it; the third forcibly kills a process that would not stop otherwise.

Cybersecurity relevance

Signals are practical for incident response — for example, terminating a malicious process (prefer SIGTERM, fall back to SIGKILL) once identified by PID. Understanding that SIGKILL cannot be caught matters when a process resists a graceful stop, while knowing SIGHUP reloads config is useful for applying changes. Note that stopping a malicious process is only part of response; you must also address how it started (lineage) and persistence, or it may return.

Common mistakes

• Reaching for kill -9 first — SIGTERM (graceful) should be tried before SIGKILL (forceful, no cleanup).
• Thinking kill only terminates — it sends any signal, including reload (SIGHUP) and pause/resume.
• Killing a symptom without addressing the cause — a malicious process may respawn if its source/persistence remains.

Key takeaways

• Signals are notifications sent to processes (via kill by PID) instructing actions like terminate, reload, pause, or resume.
• Common signals: SIGTERM (15, graceful stop, default), SIGKILL (9, forceful, uncatchable), SIGINT (2, Ctrl+C), SIGHUP (1, reload config), SIGSTOP/SIGCONT (pause/resume).
• Prefer graceful SIGTERM before SIGKILL; signals aid incident response, but stopping a process also requires addressing how it started.

Check your understanding

• What is the difference between SIGTERM and SIGKILL, and why try SIGTERM first?
• Which signal is commonly used to make a service reload its configuration without a full restart?