Zombie process

Processes that stay zombies for a long time are usually an error and can cause a resource leak.

The parent can read the child's exit status by executing the wait system call, whereupon the zombie is removed.

However, if a parent fails to call wait, the zombie will be left in the process table, causing a resource leak.

On modern UNIX-like systems (that comply with SUSv3 specification in this respect), the following special case applies: if the parent explicitly ignores SIGCHLD by setting its handler to SIG_IGN (rather than simply ignoring the signal by default) or has the SA_NOCLDWAIT flag set, all child exit status information will be discarded and no zombie processes will be left.

[2] Zombies that exist for more than a short period of time typically indicate a bug in the parent program, or just an uncommon decision to not reap children (see example).

If the parent program is no longer running, zombie processes typically indicate a bug in the operating system.

As with other resource leaks, the presence of a few zombies is not worrisome in itself, but may indicate a problem that would grow serious under heavier loads.

Therefore, the command to show disk usage will not count the deleted files whose space cannot be reused due to the zombie holding the filedescriptor.

Each of these child processes (detected by the fact that fork() returned zero) prints a message, sleeps, and exits.

It waits for the child that slept 10 seconds first; all the others have long since exited, so all of the messages (except the first) appear in quick succession.