Why Is It Called 'Zombie'? — The Origin of the Term

It has died. Its resources are released. Its memory is freed. Its exit code sits in a tiny slot, waiting for someone — anyone — to acknowledge it. But no one comes. So it lingers. Not alive. Not quite gone. A process that has ceased to be, but refuses to disappear from the system’s records. That, in Unix terminology, is a zombie.

The Story

The word “zombie” entered English through Haitian Creole zonbi, referring to a reanimated corpse controlled by a sorcerer. In Haitian folklore, a zombie is not the flesh-hungry monster of Hollywood — it’s a person whose soul has been captured, forced to work as a soulless slave. The Western idea of zombies as undead predators emerged largely from George A. Romero’s 1968 film Night of the Living Dead.

When Unix developers needed a name for a process that had exited but still occupied a process table entry, “zombie” was perfect. The process is dead — it has finished executing, its memory has been deallocated, its file descriptors are closed — but a small vestige remains visible in the process table, like the walking dead.

The mechanics are simple:

1. A child process calls exit() to terminate.
2. The child sends a SIGCHLD signal to its parent.
3. The parent is supposed to call wait() or waitpid() to read the child’s exit status.
4. Until the parent does that, the child remains in the process table as a zombie.

If the parent never reads the exit status — either because it’s buggy, busy, or negligent — the zombie persists indefinitely.

How It Evolved

Zombies became a central part of Unix systems programming lore. Every CS student learns about them. Every system administrator has had to deal with them. The metaphor is so natural that it’s now used in two distinct contexts:

Zombie processes: The Unix system phenomenon. A zombie appears as Z in ps output. Its process ID is tied up, preventing reuse. A few zombies are harmless — the parent will eventually handle them. An accumulation of zombies signals a broken parent process.

Zombie computers: Machines controlled by malware without the owner’s knowledge, used in botnets to send spam, launch DDoS attacks, or mine cryptocurrency. The computer’s owner thinks it’s fine, but it’s doing the attacker’s bidding — a soulless machine commanded by a remote master.

The zombie apocalypse scenario in computing is real: if a system forks thousands of child processes and the parent never calls wait(), the process table fills with zombies. The system runs out of process slots. New processes can’t be created. The machine effectively locks up.

Did You Know?

You can’t kill a zombie with kill -9. It’s already dead. The only way to eliminate a zombie is to kill its parent (which orphans the zombie, and init reaps it) or call waitpid() correctly. The kill command sends signals to running processes — but a zombie isn’t running.

The maximum number of processes on Linux is defined by kernel.pid_max (default 32768 on 32-bit, 4194304 on 64-bit). If zombies fill the process table, new processes fail with “Resource temporarily unavailable.”

Hollywood zombie rules don’t apply to Unix zombies. They don’t spread. They don’t infect other processes. They don’t lurch forward when you’re not looking. They just sit there, inert, waiting for a parent that may never come.

FAQ

Related Etymologies