Learning Question
How does the operating system represent a process stopping, being interrupted, or finishing?
A process has a lifetime.
It is created, runs or waits, may receive signals, and eventually exits or is terminated.
The operating system records enough lifetime state for other parts of the system to observe and clean up the process.
The first mental model is:
Process termination is OS-managed state, not merely the last source-code line being reached.
Normal Exit
A process may exit normally.
At the C level, this may happen by returning from main or calling exit.
At the OS level, the process reports an exit status.
By convention, status 0 usually means success, while nonzero values indicate different kinds of failure or special outcomes.
The meaning of a nonzero status is defined by the program or surrounding convention.
The OS preserves the status so a parent process, shell, script, or supervisor can observe it.
Termination by Signal
On Unix/Linux, a signal is a form of asynchronous notification delivered to a process or thread.
Some signals can terminate a process.
Examples include:
SIGINT, often sent by pressing Ctrl-C in a terminalSIGTERM, a polite termination request by conventionSIGKILL, a forced termination signal that cannot be caught or ignoredSIGSEGV, commonly delivered after invalid memory access
Signals are not just messages printed to the terminal.
They are OS-level events that can affect control flow, stop execution, terminate a process, or invoke a handler.
Signal Handlers
A process can install handlers for some signals.
A handler lets the process run specific code when the signal arrives.
Not every signal can be handled.
For example, SIGKILL cannot be caught or ignored on Unix/Linux.
Signal handlers also have restrictions because they interrupt normal execution.
The detailed rules are advanced, but the mental boundary is simple:
A signal can arrive outside the ordinary sequence of source-code statements.
Zombies and Waiting
When a child process exits, the kernel keeps a small amount of information about it so the parent can collect its status.
Until the parent waits for it, the exited child may remain as a zombie process.
A zombie is not still executing.
It is an exited process with status waiting to be reaped.
The parent uses a wait operation to collect that status.
After that, the kernel can remove the remaining process table entry.
Orphans and Reparenting
If a parent exits before a child, the child does not automatically disappear merely because its parent is gone.
The OS reparents the child to another process responsible for reaping it, depending on system behavior.
The important point is that process lifetime is tracked independently for each process.
Parent-child relationships affect observation and cleanup, but the child is a separate process.
Exit Status in Shells
Shells expose process exit status.
For example, scripts often branch based on whether the previous command succeeded.
This is possible because the shell started the command as a child process and waited for its completion.
The shell is not reading the child’s source code.
It is observing OS-managed termination state.
Core Mental Model
A process’s lifetime is visible through OS mechanisms such as signals, exit status, waiting, and cleanup.
When diagnosing process termination, ask:
Did the process exit normally, was it terminated by a signal, and did its parent collect the result?
Final Summary
The operating system manages process lifetime beyond ordinary instruction execution.
Signals can interrupt or terminate processes, exit status records completion, and parent processes use waiting to observe and clean up child processes.