Kill - does it kill the process right away?

Question

What does kill exactly?

I have a parent process that creates 100 (as an example) child processes one by one. At the end of any child job, I kill the child with kill(pid_of_child, SIGKILL) , and I don't see this in ps output. But if something went wrong with the parent process, and I exit(1) parent process with exit(1) (at the moment there is only one child - I can check tht in ps ), at this moment I see a lot of <defunct> processes whose ppid is the pid parent process.

How is this possible? did kill not completely destroy child processes?

Answer 1

kill doesn't kill anything. It sends signals to the target process. SIGKILL is just a signal. Now the standard action for SIGKILL is the only action, in fact, since SIGKILL cannot be processed or ignored by the process, it is to get out of this true.

The "<defunct>" process is a child that was not received, which means that the parent did not call wait() to obtain the exit status of the child. Until the parent calls wait() , the replacement process (or "zombies") will hang.

Answer 2

Whenever a process ends, regardless of how it ends ( kill or otherwise), it will remain in the kernel process table until its parent process receives exit status (using wait and friends). Leaving it in the process table, you avoid a lot of unpleasant race conditions.

If your parent process is complete, the children must be reassigned to init , which periodically reaps their children.

Answer 3

Yes, SIGKILL ends the process, but in any case (either with a normal exit or with completion), the processes have an exit status that should be supported by potential readers, since such an entry in the process table can remain until this is ready. See http://en.wikipedia.org/wiki/Zombie_process .