Exercise 3: What a Zombie Process Actually Is — Possible Solution ==================================================================== WHAT A ZOMBIE PROCESS IS ------------------------------ Per this chapter, "a zombie (shown as in ps) is a process that has already finished running, but whose exit status hasn't yet been collected by its parent process." The process itself has stopped executing - it's not doing any work, using any CPU, or holding any meaningful memory - but a small trace of it (its exit status) remains until its parent explicitly acknowledges it. WHY A SINGLE ZOMBIE USUALLY ISN'T WORTH INVESTIGATING ------------------------------ Per this chapter, "it isn't consuming meaningful CPU or memory - its actual resources are already released." A lone zombie represents a tiny, essentially harmless bookkeeping remnant, not an active resource consumer of any kind - there's nothing meaningful for it to be "causing" in terms of system load. WHAT A GROWING ZOMBIE COUNT WOULD SUGGEST INSTEAD ------------------------------ Per this chapter, "a large accumulation of zombies can exhaust the system's process table, preventing new processes from starting at all" and "a steadily growing zombie count over time points at a parent process with a genuine bug in how it manages its children." A rising count over time indicates a specific parent process is repeatedly spawning children and failing to properly clean up after them (via wait()/reaping), which is a real, ongoing bug worth investigating - distinct from the harmless, momentary appearance of a single zombie. WHY THIS WORKS AS AN ANSWER ------------------------------ It explains what a zombie is and why it's not a real resource consumer on its own, and separately explains why a growing count over time (rather than a single instance) is the actual signal worth investigating, and what kind of underlying bug it points to.