This is by design. No action is necessary on your part. There is nothing wrong. "Nothing to see here... move along... move along..."
The Unix/Linux system is founded on the notion that you can get things done by creating small, simple, fairly special-purpose programs and stringing them together. For example, the command-line features '|' ("pipe") and '&' ("background execution") are built on this.
So... you (or your program) fires-off another process to do this-or-that, and then, say, waits for it to finish. (Or, eventually notices that it
has finished.)
Thought Question...
Quote:
"How can your program know the status of that 'other process' that it had launched, if that 'other process' has "already finished?"
"How could there possibly be any information (left...) to collect?"
I mean, "if it has 'finished,' doesn't that mean that it's 'like, really gone,' and so there's nothing left to look at unless you like digging in a graveyard?"
(Clever answer: "nope... 'cuz for the moment at least, it's a zombie.")
|
When that 'other process' finishes, it becomes a "zombie"
precisely so that it will be possible for your process to "notice that it has died" and to collect final-status (such as a return-code) from it.
The "zombie" state
exists to facilitate this rendezvous.
The "zombie" sits there until you inquire. The act of "waiting for the 'other process' to die," or of "noticing that it has died," serves to
reap ... as in Grim Reaper ... the zombie-process. At this point, the zombie ceases to exist.
If your process dies without inquiring as to the status of the others, the zombies will be inherited by "process #1, '
init'," a system-defined process which by-definition never dies.
init will, of course, immediately "reap" them.
(Process-table overflows are prevented by imposing reasonable limits on the maximum number of processes, "dead or alive," that you can have.)