Processes & the Process Abstraction

a zombie process

Picture a guest who has checked out, packed up, and left, but whose final bill is still sitting at the front desk unread. The guest is gone, yet a small record lingers until someone files it. A zombie process is just like that record: a process that has finished running and given up almost everything, but whose exit status is still being held, waiting for its parent to read it. It is dead but not yet cleared away.

When a process terminates, the OS frees its memory and closes its files, but it must keep a tiny remnant, the process-table entry holding the exit status, until the parent calls wait to collect it. In this in-between state the process is a zombie: it uses no CPU and almost no memory, but it still occupies a process-table slot and shows up in listings as 'defunct'. The moment the parent reaps it with wait, the OS reads out the status, removes the entry, and the zombie disappears for good.

A few zombies are completely normal and brief, every terminated child is a zombie for the instant between exiting and being reaped. The real problem is a parent that never reaps its children: zombies then accumulate, and since the process table is finite, a flood of them can eventually exhaust process-table slots and prevent new processes from starting. Two clarifications worth fixing: you cannot kill a zombie (it is already dead, so a kill signal does nothing); the way to clear it is to make its parent reap it, or, if the parent itself exits, init inherits and reaps the orphaned zombies.

A program forks many children to do quick tasks but never calls wait. Each child finishes and becomes a zombie marked 'defunct'; over hours the listing fills with zombies, none of which can be killed.

Forgetting to wait leaves zombies; you fix it by reaping, not by killing.

You cannot kill a zombie; it is already dead. It clears only when its parent reaps it with wait, or when init inherits and reaps it after the parent exits.

Also called
defunct processzombie殭屍行程defunct 行程