[root /var/www/html 06:08:47]

# man top

 w: S  --  Process Status
          The status of the task which can be one of:
             D = uninterruptible sleep
             R = running
             S = sleeping
             T = traced or stopped
             Z = zombie

“A child that terminates, but has not been waited for becomes a 'zombie.' The kernel maintains a minimal set of information about the zombie process (PID, termination status, resource usage information) in order to allow the parent to later perform a wait to obtain information about the child.”man wait(2)

http://www.rack.org/sysadmin/ascii/02.01/weinstei/weinstei.txt:

“Zombies are nothing harmful, just a sign that the parent process has yet to collect the status of its sub-processes that have exited. Causing the parents to wake up and reap their children will cause the zombies to go away.”

O'Reilly Perl Cookbook:

16.19. Avoiding Zombie Processes
16.19.1. Problem

Your program forks children, but the dead 
children accumulate, fill up your process 
table, and aggravate your system administrator.

But we don't have orphaned zombies on our system. They are not filling up the process table. They come and go in an orderly fashion.

ps aux | awk '{ print $8 “ ” $2 }' | grep -w Z

[23:21:53]
# ps aux | awk '{ print $8 " " $2 }' | grep -w Z
Z 29838
Z 29853
Z 29854

Three zombies found at 23:21:53.

[23:32:42]
# ps aux | awk '{ print $8 " " $2 }' | grep -w Z
Z 29956
Z 29958
Z 29959

Three entirely different zombies eleven minutes later.

[23:32:50]
# ps aux | awk '{ print $8 " " $2 }' | grep -w Z

0 zobmies 8 seconds later.

[23:32:55]
# ps aux | awk '{ print $8 " " $2 }' | grep -w Z
Z 30073

1 zombie 5 seconds later.

[23:32:59]
# ps aux | awk '{ print $8 " " $2 }' | grep -w Z
Z 30117
Z 30118

2 zombies 4 seconds later.

[23:33:02]
# ps aux | awk '{ print $8 " " $2 }' | grep -w Z

0 zombies 3 seconds later.

<code> [23:33:05] # ps aux | awk '{ print $8 “ ” $2 }' | grep -w Z Z 30161 <code>

1 zombie 3 seconds later.

None of the zombies are orphans. They only stay on the list until the result code is checked, then they vanish.

The process ids increase from 29838 to 30161 over the course of the experiment.

“… in all my years dealing with UNIX and Linux systems, I've never seen anything that spawns threads and leaves them behind like that.”

They are not “left behind.”

A zombie is not necessarily an orphan.

Some zombies are left in Dead Care while their parents are busy; when the parents come back, the dead babies get reaped and disappear forever.

The zombies in Dead Care are quiet and well-behaved. When they have fulfilled their mission by providing the result code from the process, they go away in peace. They do not hang around like the orphaned zombies whose results are unwanted and whose presence is meaningless.

“Under UNIX, a process does not really exit. Instead, it returns to its parent. Typically, a parent process waits for its child process, and obtains a return value. However, our daemon process cannot simply stop and wait. That would defeat the whole purpose of creating additional processes. But if it never does wait, its children will become zombies–no longer functional but still roaming around.

“For that reason, the daemon process needs to set signal handlers in its initialize daemon phase. At least a SIGCHLD signal has to be processed, so the daemon can remove the zombie return values from the system and release the system resources they are taking up.”Free BSD Developers' Handbook

This text is using a non-standard definition of 'zombie.' It is conflating 'zombie' and 'orphan.' The two concepts are not identical as shown below.

• Source: books.google.com--Interprocess communications in Linux

• Source: orphanzombie.pdf

1. Parent and child exit together.
2. Normal Zombie: the child waits until the parent retrieves the return code, then exits gracefully.
3. Orphan Zombie converted to a Normal Zombie: Process 0 adopts the child, giving it a parent; then, acting as a good parent should, process 0 acts as if it cares, looks at the return result, and lets the newly normalized Zombie go in peace.
4. Orphan converted to a Normal Zombie: the parent runs away from the child, turning the child into an orphan; when the child exits, it goes onto the Zombie list. Process 0 adopts the child, giving it a parent; then, acting as a good parent should, process 0 acts as if it cares, looks at the return result, and lets the nely normalized Zombie go in peace. (So, actually, the arrow from the diagram should run over to the “Orphan Zombie” box in path #3. Once the Orphan gets turned into an “Orphan Zombie,” the procedure is identical to the third path).
5. An abandoned child (i.e., Orphan) that never exits is trouble. Because it never exits, it never gets turned into a an adopted Orphan Zombie, never returns a result, and never lets go of its resources.

• Source: books.google.com--UNIX systems programming: communication, concurrency, and threads

• Source: books.google.com--Unix: The Complete Reference

Copying the main lines from the capture:

“When a process issues the exit call, the kernel disables all signal handling associated with the process, and converts the process into the zombie state. A process in the zombie state is not alive; it does not use any resources or accomplish any work. But it is not allowed to die until the exit is acknowledged by the parent process.

“If the parent does not acknowledge the death of the child (because the parent is ignoring the signal, or because the parent itself is hung), the child stays around as a zombie process. …

“Because a zombie process consumes no CPU time and is attached to no terminal, the STIME and TTY fields are blank. In earlier versions of the UNIX System, the number of these zombie processes could increase and clutter up the process table. In more recent versions of the UNIX System, the kernel automatically releases the zombie processes.”

Demonstration of how zombies come and go on our system.