Help : <exiting> cannot be killed

[William LeFebvre]

Okay, let's see if I can get this right.  I guess I should warn readers
that I learned all this initially while working with 4.1 BSD.  But I
seriously doubt that something this low-level and fundamental has changed
substantially.

A process that "ps" shows as <exiting> is usually in a state that the
kernel calls the "zombie" state.  When you create a subprocess under Unix,
you can wait for its completion by calling the "wait" or "wait3" system
calls.  At that time, you find out how it exited.  If it was forced by a
signal, you find out which signal caused it to quit.  If it called "exit"
you get the exit number back.  But when a child actually exits, the kernel
has to store this information somewhere until the parent actually asks for
it.  So the kernel frees up as of the resources that the child used as
possible (swap and page space, virtual memory maps, real memory, files,
etc.), but it hangs on to the "proc" structure (and maybe the "user"
structure, but I don't think so) so that it has a place to put this
information.  A process in this "almost exited" state is a zombie (it's
almost dead).

So, if a process creates many children but never calls "wait" and never
exits itself, when the children exit they will turn into zombies.  You
can't kill a zombie process because it's already on its way out.  However,
once the parent exits, all its children are inherited by the "init"
process, pid 1.  Init always waits for children, so any zombie processes
that it inherets will immediately be "waited" for and will go away.

It is possible that an <exiting> process is really waiting for some sort
of final cleanup before becoming a zombie.  I saw this happen all too
frequently under 4.2 BSD.  I can't recall now if they were actually in the
zombie state or were still in some other kernel state.  But the only way
to get rid of them was to reboot.  I have never seen that under SunOS.

			William LeFebvre
			Sun-Spots moderator
			Department of Computer Science
			Rice University
			<phil at Rice.edu>