What is a zombie process?
Why Interviewers Ask This
Candidates at the intermediate level are expected to not only know this concept but explain the trade-offs involved. Interviewers use this question to see if you can reason about design decisions, not just recall facts.
Answer
A zombie process is a process that has terminated (exit() called, or killed) but whose entry still remains in the process table because the parent hasn't yet called wait() to read the child's exit status. Why zombies exist: When a child process terminates, its resources (memory, file descriptors, threads) are released. However, its PCB entry is kept in the process table — it holds the exit status (return code) that the parent must eventually read via wait()/waitpid(). This is necessary: the parent may need to know how the child ended. The child is "dead" but its record persists until acknowledged. Process state Z (zombie): visible in ps aux as Z or defunct. A zombie uses virtually no resources — just a process table slot. Problem: if a parent creates many children without calling wait(), zombie processes accumulate. If process table fills up → cannot create new processes → system instability. Creating a zombie: pid_t pid = fork(); if (pid == 0) { exit(0); // Child exits immediately } else { sleep(100); // Parent doesn't call wait() -- child is zombie for 100 seconds } . Fixing zombie accumulation: parent calls wait() or waitpid(); use SIGCHLD signal handler to call wait() when a child terminates; double-fork trick — fork a child that immediately forks again and exits, orphaning the grandchild which is adopted by init (PID 1) which always calls wait(). Orphan process: a process whose parent has terminated before calling wait(). The orphan is reparented to init (PID 1) which calls wait() for it — no zombie.
Common Mistake
A common mistake is memorizing definitions without understanding implications. When asked this question, go one level deeper — explain what happens when this concept is misused or ignored.