grumpy

You're referring to zombie processes.

When a parent process spawns a child it is possible for the child to exit before before the parent knows about it. When that happens, the system keeps information about the child process in case the parent needs it (eg to check the exit status, etc). The parent needs to call wait() to get information it might need. If the parent hasn't done that, then the child becomes a zombie (with ps, the child will typically have a Z in it's status to indicate this). It consumes no resources (as it is no longer running) except for an entry in the system process table. That becomes a problem for the system if there are too many zombies, as the system process table is finite;. It can also be a problem for the user who created the child (i.e. who ran the parent, which ran the child) as most systems limit the number of processes any user can have going and that limit is less generous than what is available to the system. Zombies cannot be killed using the kill command (as they are not running, and cannot respond to signals).

The real way to stop zombies is for the parent to call wait() [or a related function], such as checking the child's exit status. One way to stop them under some flavours of unix if the parent is still active is to send a SIGCHILD (value 18) signal to the parent, which tells parents to kill all their children. Unfortunately, not all versions of unix support this by default, so we come back to the problem of having to design the parent to do it (by writing a signal handler that does the work of killing the children).

If the parent dies before it killing it's children the zombies are inherited by the init process (which has PID of 1: it is the first process launched by the system when starting unix). On some forms of unix, init periodically cleans up the zombies it has adopted. On some systems, init will periodically clean up it's zombie children, but system configuration settings or a bug can prevent that (init does other work, and has to wait for other things to happen; if those things don't happen ....). On some systems, init can be told (by sending a SIGCHILD signal to it) to terminate it's children --- but init is a system process, so normal users can't do that. The net effect is that init does not necessarily kill it's adopted children. The only way then is to shutdown the system (during which init terminates all processes on the system with prejudice) and restart.

There are many human parents who would like to have similar abilities to unix parent processes.