How Does Process Termination Work in an OS?
Learn how process termination works — exit(), SIGKILL vs SIGTERM, zombies, and cleanup — with an OS interview question answered.
Expected Interview Answer
Process termination happens either voluntarily, when a process calls exit() after finishing or hitting an unrecoverable error, or involuntarily, when the OS or another process kills it via a signal, and in both cases the kernel reclaims resources and stores an exit status for the parent to collect.
On a normal exit, the process calls exit() (directly or by returning from main), which runs registered cleanup handlers, closes open file descriptors, flushes buffers, and hands an exit status code back to the kernel; the kernel then frees the process’s memory pages, closes its remaining kernel resources, and moves it into the zombie state, keeping only its PCB and exit status until the parent calls wait() or waitpid() to retrieve them, after which the PCB itself is freed. Involuntary termination happens when the OS delivers a signal like SIGKILL (which cannot be caught or ignored and terminates immediately) or SIGTERM (which can be caught for graceful shutdown), commonly triggered by another process, resource limit violations, or the OS itself under memory pressure via the OOM killer. Terminating a process also has cascading effects: any child processes it had are orphaned and reparented, any locks or semaphores it held may need to be released or detected as abandoned, and any pipes or sockets it owned are closed, which can generate SIGPIPE or connection-reset errors in processes on the other end. Properly designed programs register cleanup handlers or trap SIGTERM so they can release resources gracefully instead of leaving inconsistent state behind.
- Distinguishes voluntary exit() from involuntary signal-based termination
- Explains why a terminated process briefly persists as a zombie
- Covers cascading effects: orphaned children, released locks, closed sockets
- Motivates graceful shutdown handling via SIGTERM over SIGKILL
AI Mentor Explanation
Process termination is like a player’s innings ending: a voluntary exit is like being caught out fairly, walking off after signaling the umpire, with the scorer recording the final tally (exit status) for the captain to review later. An involuntary termination is like being forced off for a serious injury (SIGKILL) with no chance to finish the shot, versus being asked to retire due to bad light (SIGTERM), where they can at least walk off in an orderly way and hand over their gear.
Step-by-Step Explanation
Step 1
Termination trigger
The process calls exit() voluntarily, or the OS/another process delivers a termination signal like SIGKILL or SIGTERM.
Step 2
Cleanup
Registered exit handlers run (if the process was not killed by SIGKILL), buffers flush, and file descriptors close.
Step 3
Resource reclamation
The kernel frees memory pages and most kernel resources, moving the process into the zombie state with its exit status stored.
Step 4
Reaping
The parent calls wait()/waitpid() to collect the exit status, after which the kernel frees the remaining PCB entry.
What Interviewer Expects
- Distinguishing voluntary exit() from involuntary signal-based kills
- Explaining SIGKILL vs SIGTERM and why graceful shutdown matters
- Knowing why a terminated process persists as a zombie until reaped
- Awareness of cascading effects: orphaned children, released locks, closed handles
Common Mistakes
- Thinking SIGKILL and SIGTERM behave identically
- Forgetting that a process persists as a zombie until wait() is called
- Not mentioning cascading effects on children, locks, or open handles
- Assuming resources are always released instantly with no OS bookkeeping
Best Answer (HR Friendly)
“A process can end on its own once it finishes its work, cleaning up after itself and reporting how it went, or it can be forcibly stopped by the operating system or another program, sometimes instantly with no warning and sometimes with a polite request to wind down first. Either way, the operating system keeps a small record of how the process ended until whatever launched it acknowledges that, so nothing is left dangling.”
Code Example
#include <signal.h>
#include <stdlib.h>
#include <unistd.h>
volatile sig_atomic_t shutting_down = 0;
void handle_sigterm(int sig) {
shutting_down = 1; /* set a flag; do real cleanup in main loop */
}
int main(void) {
signal(SIGTERM, handle_sigterm);
while (!shutting_down) {
/* ... normal work ... */
}
/* flush buffers, close files, release locks here */
exit(0);
}Follow-up Questions
- Why can SIGKILL not be caught, unlike SIGTERM?
- What happens to a process's open file descriptors on termination?
- How does the OOM killer decide which process to terminate?
- What is the difference between a zombie and an orphan process?
MCQ Practice
1. Which signal cannot be caught, blocked, or ignored by a process?
SIGKILL is handled directly by the kernel and forces immediate termination, bypassing any handler the process might register.
2. Why does a terminated process temporarily remain as a zombie?
The kernel keeps a minimal PCB entry with the exit status so the parent can retrieve it via wait(), then frees the entry.
3. What commonly triggers the OS to forcibly terminate a process under memory pressure?
When physical memory is critically low, the OOM killer selects and kills a process (often the largest consumer) to free memory.
Flash Cards
What is the difference between SIGKILL and SIGTERM? — SIGKILL forces immediate termination and cannot be caught; SIGTERM can be caught for graceful shutdown.
Why does a process become a zombie after exit()? — Its exit status is kept in the PCB until the parent collects it via wait().
What happens to a terminated process's children? — They are orphaned and reparented, typically to init.
What commonly forces involuntary termination under memory pressure? — The OS's OOM (out-of-memory) killer.