Questions: Process Termination and Resource Cleanup

Question 1

A process calls exit(0). What state does it enter immediately afterward?

• A. It is permanently removed from the process table and all resources are freed
• B. It enters zombie state, preserving its exit status until the parent calls waitpid()
• C. It is suspended and waits for the parent process to restart it
• D. It is reparented to init and continues running in the background

Answer: (B)

After exit(), the OS closes file descriptors, frees memory pages, and removes the process from the scheduler — but does NOT remove it from the process table. The minimal zombie entry persists, holding the exit status code. This is intentional: the parent process needs to collect that status via waitpid(). Only after the parent reaps the zombie is the process table entry finally freed.

Question 2

A long-running server forks hundreds of worker processes but never calls waitpid(). After several days, the server can no longer fork new processes. What is the most likely cause?

• A. The server has run out of heap memory from accumulating child data
• B. Zombie processes have accumulated and exhausted the process table
• C. The worker processes became orphans and are consuming all CPU
• D. File descriptor limits were reached because each child inherits the parent's descriptors

Answer: (B)

Each worker exits and becomes a zombie — a minimal process table entry holding the exit status. Zombies consume no CPU or memory, but they do occupy process table slots. The process table has a finite size (typically 32,768 or similar). When it fills with uncollected zombies, fork() fails because there's no room for a new entry. The fix is to call waitpid() (or handle SIGCHLD) to reap children promptly.

Question 3

When a process calls exit(), its memory pages and file descriptors are freed, and it is permanently removed from the process table.

• T. True
• F. False

Answer: False

Memory pages and file descriptors are indeed freed on exit(), but the process is NOT removed from the process table. It enters zombie state — a skeletal entry that holds only the exit status code and PID. It consumes no memory or CPU, but the table entry remains until the parent reaps it with waitpid(). The zombie exists solely so the parent can collect the exit status; removing it prematurely would lose that information.

Question 4

If a parent process terminates before its children, the OS reparents the orphaned children to the init process (PID 1) rather than terminating them.

• T. True
• F. False

Answer: True

The kernel guarantees that every process always has a living parent to collect its exit status. When a parent dies, its children become orphans and are automatically adopted by init (or systemd in modern Linux). Init continuously calls wait() on its children, so orphan zombies are promptly reaped when they exit. The system is designed so zombie accumulation cannot result from parent death.

Question 5

What is a zombie process, why does it exist, and what event finally removes it from the process table?

Model answer: A zombie is a process that has exited but whose process table entry persists because the parent hasn't yet collected its exit status. It exists because the OS needs a place to store the exit status code until the parent reads it — like a receipt waiting to be picked up. The zombie consumes no CPU or memory, only a process table slot. It is finally removed when the parent calls waitpid() (or wait()), which reads the exit status and signals the kernel to free the entry.

The zombie state is the mechanism that makes the parent-child cleanup contract work. Without it, exit status information would be lost the moment a process dies. The design is deliberate: exit clears the expensive resources (memory, file descriptors) immediately, but preserves the cheap status data until the parent is ready to receive it. Long-running servers must reap children promptly to prevent zombie accumulation from exhausting the process table.