ECE344 Fall 2026 (Sec 1) Lec 5 - Process Management

Overview

Jon Eyolfson explains Linux process management through process states, parent-child relationships, and the requirement that a parent collect each child’s exit status with wait or waitpid. Using /proc, htop, systemd, and xv6 examples, he shows how uncollected terminated children become zombies, how surviving children become orphans and are adopted by init or a subreaper, and how fork return values shape a process tree.

Key takeaways

Linux process state R covers both executing and runnable processes, while S, D, T, and Z distinguish interruptible sleep, uninterruptible sleep, stopped execution, and terminated-but-uncollected children.
A child’s exit status remains available only until its parent collects it; wait or waitpid returns the child PID and allows the kernel to remove the child’s process record.
A zombie is already terminated but not yet acknowledged, whereas an orphan is still alive after its parent exits; a process can become an orphan first and later be reaped after termination.
PID 1, commonly systemd on modern Linux, creates or manages system processes and collects adopted orphans; Linux subreapers can intercept orphan adoption before PID 1.
After fork, parent and child resume at the same point with separate memory and different return values, but the child inherits the parent’s variable values—not ownership of the parent’s existing children.

Chapters

0:00 Linux Process States: R, S, D, T, and Z

Linux combines running and runnable into state R, while splitting blocked processes into interruptible sleep (S) and uninterruptible sleep (D).
State T marks a stopped process, such as one paused by a debugger or Ctrl-Z; state Z marks a terminated process awaiting cleanup.
A process’s state can be inspected through its status file under /proc/<pid>, or /proc/self/status for the current process.

6:30 PID 1, systemd, and Viewing the Process Tree

After kernel initialization, Unix-like systems start init as PID 1; modern Linux commonly uses systemd, and PID 1 remains for the operating-system session.
Processes form a parent-child tree: a shell can fork a child and exec a program such as htop, while Firefox may create separate processes for tabs.
On Linux, htop’s F5 tree view displays process ancestry; numbered directories in /proc provide the underlying process list.
Containers have their own PID namespace, so their main process can appear as PID 1 even without a conventional init system.

12:00 Process IDs: Uniqueness, Reuse, and Limits

A process keeps its PID for its active lifetime; PID 1 is init, while PID 0 is reserved and not a normal process ID.
Linux eventually reuses a PID after the old process has been cleaned up, so PIDs are unique among active processes rather than permanently unique.
The maximum PID is configurable: the lecture contrasts older defaults around 32,000 with modern systems that can allow roughly 4 million.

14:00 Why Parents Must Collect Child Exit Status

A process terminates with an exit status between 0 and 255, but the kernel retains the child’s process record until its parent acknowledges the termination.
The wait system call blocks until a child terminates, returns that child’s PID, and can write encoded status information through an integer pointer.
Use WIFEXITED and WEXITSTATUS to interpret the status value; waitpid can target a specific child, while PID -1 means any child.
A parent can pass NULL when it does not need the status, but it must still collect the child so the kernel can clean it up.

20:15 Testing wait with fork and a Two-Second Child

After fork, the parent receives the child’s PID and the child receives 0, allowing the program to distinguish their execution paths.
In the example, the child sleeps for two seconds and exits with status 0 or 42; the parent’s wait blocks until termination.
The parent checks WIFEXITED and extracts the result with WEXITSTATUS, then the child’s PID disappears from /proc after wait completes.
Returning from main is equivalent to calling exit with the same status in standard C.

25:00 Zombie Processes and an Uncollected Child

A zombie is a terminated child whose parent has not yet called wait; the kernel retains its PID and exit status for collection.
The demonstration has a child exit after two seconds while its parent delays collection, then reads the child’s state from /proc and observes Z.
A brief zombie interval is normal while a parent collects a child, but many neglected zombies waste kernel process-table resources.
Linux can notify a parent that a child terminated with a signal, but the parent can ignore that notification and leave the zombie uncollected.

29:00 Orphan Adoption by init and Subreapers

An orphan is a still-running process whose parent has exited; Linux reparents it rather than leaving it without a parent.
The default adopter is PID 1, but Linux assigns an orphan to the nearest ancestor process that opted in as a subreaper.
systemd can act as a subreaper, explaining why the orphan example’s child receives a new parent PID other than 1.
Init also reaps adopted children; xv6’s init.c illustrates this with a loop that repeatedly calls wait.

37:00 Process Management Rules and the Fork Puzzle

Parents should wait on each direct child: failing to do so can leave zombies, while a parent that exits first creates an orphan.
A process may intentionally become an orphan, but it will be reparented; a zombie is specifically a terminated child still awaiting acknowledgment.
The fork puzzle adds a second fork inside the parent branch to test how many processes are created and which process owns each child.

40:00 Tracing Fork Clones and Independent Memory

The trace labels the original process 100 and its first child 101; after the first fork, only process 100 enters the branch where the PID is greater than zero.
When process 100 forks again, it creates process 102; process 102 inherits a copy of the variable whose value is 101.
Forked processes continue from the fork call rather than restarting main; their return values differ, but an ignored return value does not distinguish their subsequent code paths.
Process 102 is a child of 100, not 101: fork copies process memory, not ownership of existing child processes.

47:00 Wait Errors, Exit Ordering, and an Orphaned Child

Process 102 has no children, so its wait call fails instead of blocking; the example later checks for a return value of -1 and handles the error.
Process 101 sleeps for two seconds and exits with status 42, while process 100 waits for whichever of its two children terminates first.
Because process 102 fails and exits first, process 100 reaps it and then exits before process 101 finishes sleeping.
Process 101 is an orphan, not a zombie, when process 100 exits; it is reparented to init or a subreaper and can be collected after it terminates.

Summary, takeaways, and chapters were generated by AI from the video's transcript and may contain errors. The video belongs to its creator, Jon Eyolfson.