Which Of The Following Represents A Signal In Linux: Complete Guide

Ever wonder why a simple “Ctrl‑C” can stop a stubborn process in Linux?
It’s all about signals—tiny messages that tell programs what to do.
If you’ve ever typed a command and seen it die instantly, you’ve already interacted with a signal. But how do they work? What are the most common ones? And why should you care? Let’s dive in No workaround needed..

What Is a Signal in Linux

A signal is a lightweight, asynchronous notification sent from the kernel to a process (or from one process to another) to indicate that something noteworthy has happened. Because of that, think of it as a text message that pops up on your phone: “Hey, your battery is low” or “Your friend just sent a photo. ” In Linux, signals can tell a process to pause, resume, terminate, or even handle a custom event Still holds up..

Signals are identified by numbers (1–64 on most systems) and names (e.Also, g. , SIGINT, SIGTERM, SIGKILL).

• Hardware interrupts (e.g., pressing Ctrl‑C in a terminal)
• System events (e.g., a child process exiting)
• User requests (e.g., kill command)

When a signal arrives, the kernel interrupts the process’s normal flow and jumps to a signal handler. If no handler is defined, the process follows the default action, which could be to terminate, ignore, or stop Simple, but easy to overlook..

Why It Matters / Why People Care

Understanding signals is more than a geeky curiosity; it’s essential for:

• Debugging: A process that “hangs” might be stuck in a signal handler.
• Process control: System administrators use signals to gracefully stop services (SIGTERM) or force them down (SIGKILL).
• Programming: Writing dependable scripts or applications that respond to user input or system events.
• Security: Misusing signals can lead to denial‑of‑service or privilege escalation.

In practice, missing a signal can mean a runaway process hogging CPU, a service that never shuts down cleanly, or a script that never knows when to finish. Knowing which signals exist and how to handle them turns chaos into control And that's really what it comes down to..

How It Works (or How to Do It)

Below we break down the core signals you’ll encounter and show how to send, catch, and react to them.

Common Signals and Their Defaults

Note: Numbers can vary on non‑x86 architectures.

Sending Signals

The simplest way to send a signal is the kill command. The syntax is:

kill -SIGNAL PID

Examples:

kill -SIGINT 1234        # Same as kill -2 1234
kill -s SIGTERM 1234     # More explicit
kill -9 1234             # SIGKILL

You can also use pkill or killall to target by name:

pkill -SIGTERM myservice

Catching Signals in Shell Scripts

Shells like Bash let you trap signals using trap. For example:

#!/usr/bin/env bash
trap 'echo "Caught SIGINT, cleaning up..."; exit 0' INT
# or
trap 'echo "Caught SIGTERM"; exit 0' TERM

# main loop
while true; do
  echo "Running..."
  sleep 5
done

This script will print a message and exit cleanly when you press Ctrl‑C or send SIGTERM.

Catching Signals in C/C++

In C, you register a handler with signal() or sigaction():

#include 
#include 
#include 

void handler(int sig) {
    printf("Caught signal %d\n", sig);
    exit(0);
}

int main() {
    signal(SIGINT, handler);
    while (1) pause(); // wait for signals
}

sigaction() offers more control (e.On the flip side, , blocking other signals during handling). g.Use it when you need dependable handling That's the part that actually makes a difference..

Signal Safety

Only a handful of functions are async‑signal safe, meaning they can be safely called from within a signal handler. The list includes write(), _exit(), and signal(). If you need to do more complex work, set a flag in the handler and handle it in the main loop And that's really what it comes down to..

Signal Masks

Processes can block signals temporarily using sigprocmask() or pthread_sigmask() (for multithreaded programs). This is useful when you’re in a critical section and don’t want to be interrupted Most people skip this — try not to..

Common Mistakes / What Most People Get Wrong

1. Assuming kill -9 is always safe
   SIGKILL stops the process immediately, bypassing cleanup. Use it only when a graceful shutdown fails.

2. Ignoring SIGCHLD in parent processes
   Without handling SIGCHLD, zombie processes pile up. Either reap children with wait() or ignore the signal.

3. Overusing SIGUSR1/SIGUSR2 for custom protocols
   These signals are meant for user‑defined purposes, but relying on them for complex communication can be fragile. Consider IPC mechanisms like sockets or shared memory Easy to understand, harder to ignore. No workaround needed..

4. Assuming signals are synchronous
   Signals are asynchronous. A handler can run at any time, even mid‑system call. That’s why only async‑signal safe functions should be used inside handlers.

5. Not testing signal handling in production
   A script that works locally may behave differently under load or when run as a service. Always test with real signals.

Practical Tips / What Actually Works

• Graceful shutdown first: Prefer SIGTERM over SIGKILL. Give your service time to close sockets, flush logs, and release resources.
• Use trap for cleanup in scripts: Even a simple trap EXIT ensures rm -f /tmp/tmpfile runs on exit or error.
• use systemd for service signals: systemd sends SIGTERM then SIGKILL after a timeout. Configure TimeoutStopSec= to control the grace period.
• Avoid busy loops in handlers: Keep handlers short. Set a flag and handle the heavy lifting in the main loop.
• Document signal behavior: In your README, list which signals your program handles and what it does. This helps operators and other developers.

FAQ

Q1: What happens if I send SIGTERM to a process that doesn’t handle it?
A1: The default action is to terminate the process. If the process ignores the signal (SIG_IGN), it will keep running until you use SIGKILL.

Q2: Can I send a signal to all processes owned by a user?
A2: Yes, use killall -u username or pkill -u username. Be cautious; it can stop critical system services.

Q3: How do I know which signals a process is ignoring or handling?
A3: Use cat /proc/<pid>/status to see signal dispositions, or strace -p <pid> to watch signals in real time Nothing fancy..

Q4: Is SIGSTOP the same as SIGTSTP?
A4: No. SIGSTOP stops a process unconditionally (cannot be caught or ignored). SIGTSTP is the terminal stop signal (Ctrl‑Z) that can be caught or ignored.

Q5: Why does my script hang after I send SIGINT?
A5: Likely you have a long‑running command that doesn’t terminate on SIGINT, or your trap handler is blocking. Check that the handler exits promptly Simple, but easy to overlook. Practical, not theoretical..

Signals are the unsung heroes of process control in Linux. Think about it: they let you pause, stop, or customize the behavior of programs without touching the code. Mastering them means you can write cleaner scripts, build more resilient services, and keep your system from turning into a runaway chaos machine It's one of those things that adds up..

Next time you hit Ctrl‑C and see your process die, remember: you just sent a signal. And now you know how to wield that power wisely.