## Question Explain how Unix process signals and process reaping work. Cover what `kill` actually does, how `SIGTERM` differs from `SIGKILL`, how a zombie process is created, and the role of a parent process or PID 1 in removing zombies. Then describe how you would investigate a growing zombie count without blindly terminating processes. ### Constraints & Assumptions - Discuss standard Unix semantics; note where behavior is signal-handler or operating-system dependent. - Preserve the distinction between a process that has exited, a process that is stopped, and a process that is still running. ### Clarifying Questions to Ask - Are we discussing a normal host, a container PID namespace, or both? - Is the concern graceful shutdown, an unreaped-child leak, or a stuck live process? - Does the parent install handlers or use a process supervisor? ```hint Follow the parent-child lifecycle A zombie has already finished executing. Its small kernel record remains so the parent can collect status with a wait operation. ``` ### What a Strong Answer Covers - Signal delivery, default actions, handlers, blocking, and the uncatchable nature of `SIGKILL`. - `kill` as a signal-sending interface rather than a guarantee of termination. - Exit status retention, `wait` or `waitpid`, orphan adoption, PID 1, and subreapers. - Investigation of the zombie's parent, child-reaping loop, signal handling, and container init configuration. ### Follow-up Questions 1. Why does sending `SIGKILL` to a zombie not remove it? 2. What can go wrong when PID 1 inside a container does not reap descendants? 3. How would you design a supervisor to avoid both zombie leaks and accidental restart storms?