From 9c2ebc58f57a51e790d168549c04bc52226cea11 Mon Sep 17 00:00:00 2001 From: Ziheng Chen <zc328@dragons.drexel.edu> Date: Mon, 17 Feb 2025 17:24:23 +0000 Subject: [PATCH] Edit questions.md --- w6/questions.md | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/w6/questions.md b/w6/questions.md index 10cad12..1c4eb3b 100644 --- a/w6/questions.md +++ b/w6/questions.md @@ -45,10 +45,20 @@ - What is the purpose of signals in a Linux system, and how do they differ from other forms of interprocess communication (IPC)? > **Answer**: _start here_ + > Signals provide a way for processes to receive asynchronous notifications about events, such as termination requests (`SIGTERM`) or user interrupts (`SIGINT`). Unlike other IPC mechanisms (pipes, message queues, shared memory), signals do not carry data—they simply notify a process of an event. Signals are often used for handling process control (e.g., stopping or restarting services). + + + > - **`SIGKILL (9)`**: Immediately terminates a process and cannot be caught or ignored. Used when a process needs to be forcefully stopped (e.g., `kill -9 <pid>`). + > - **`SIGTERM (15)`**: Politely asks a process to terminate, allowing it to clean up resources. This is the preferred way to stop processes (e.g., `kill <pid>`). + > - **`SIGINT (2)`**: Sent when the user presses `Ctrl+C`. It allows a process to handle interruption gracefully, such as stopping an interactive program. + - Find and describe three commonly used signals (e.g., SIGKILL, SIGTERM, SIGINT). What are their typical use cases? > **Answer**: _start here_ + > + > When a process receives `SIGSTOP`, it is immediately paused (suspended) by the kernel. Unlike `SIGINT`, `SIGSTOP` **cannot** be caught, ignored, or blocked because it is intended for immediate process suspension. This makes it useful for debugging (e.g., using `kill -STOP <pid>` to pause a process). + - What happens when a process receives SIGSTOP? Can it be caught or ignored like SIGINT? Why or why not? -- GitLab