4

what does kill exactly do?

I have a parent process which is creating 100 (as an example) child processes one after another. At the end of any child's job, I kill the child with kill(pid_of_child, SIGKILL) and I cannot see that in ps output. But if something goes wrong with the parent process and I exit from the parent process with exit(1) (at this point only 1 child is there - I can check tht in ps), at that point I see a lot of <defunct> processes whose ppid is pid of parent process.

How is that possible? did kill not kill the child processes entirely?

hari
  • 9,439
  • 27
  • 76
  • 110
  • 1
    @ChrisO: The kernel does not reap zombies, ever. Only `init` reaps zombies, and only zombies that are its own children. – Dietrich Epp Dec 12 '11 at 01:13
  • @Dietrich Epp, thanks for the correction. – Chris O Dec 12 '11 at 01:14
  • I have a follow-up question: http://stackoverflow.com/questions/8481803/can-a-child-process-go-defunct-without-its-parent-process-dying – hari Dec 12 '11 at 22:33

3 Answers3

8

kill doesn't kill anything. It sends signals to the target process. SIGKILL is just a signal. Now, the standard action for SIGKILL -- the only action, actually, since SIGKILL can't be handled or ignored by a process -- is to exit, that's true.

The "<defunct>" process is a child that hasn't been reaped, meaning that the parent hasn't called wait() to retrieve the exit status of the child. Until the parent calls wait(), the defunct (or "zombie") process will hang around.

Ernest Friedman-Hill
  • 80,601
  • 10
  • 150
  • 186
  • 2
    "Now, the standard action for SIGKILL is to exit, that's true." - It's worth mentioning that there cannot be a "nonstandard action" for it, since `SIGKILL` cannot be caught or ignored (contrast e.g. with `SIGTERM`, which is often caught to perform a clean process termination). – Matteo Italia Dec 12 '11 at 01:15
  • Thanks Ernest and @Dietrich Epp: So, when `kill` is called for a pid, that pid cannot be seen in the `ps` output but that does not mean, its all done and that pid has been given back to process table. - is that a correct assumption? So, parent should `wait` right after `kill`ing the child to avoid ``s? – hari Dec 12 '11 at 01:35
  • 1
    Whether you'll see the child in your `ps` output depends on the options you give to `ps` (and the specific implementation of that tool I suppose). But yes, calling `wait()` when a child is exiting is a good idea. You normally get a `SIGCHLD` signal when a child exits; this is a fine time to call `wait()`, in the handler for that signal. – Ernest Friedman-Hill Dec 12 '11 at 02:00
  • So, I can call wait() right after kill(), something like this: kill (pid_of_child, SIGKILL); waitpid(pid_of_child, &status, WNOHANG); - would that be a correct way? – hari Dec 12 '11 at 06:01
  • Yes (if you're killing your own child process.) The parent process has to be the one to call `wait()`. – Ernest Friedman-Hill Dec 12 '11 at 13:15
7

Whenever a process ends, no matter how it ends (kill or otherwise), it will stay in the kernel's process table until its parent process retrieves its exit status (with wait and friends). Leaving it in the process table avoids a number of nasty race conditions.

If your parent process has exited, the children should get reassigned to init, which periodically reaps its children.

Dietrich Epp
  • 205,541
  • 37
  • 345
  • 415
  • So, if I want to avoid /Zombies, what should parent do? In my case, in error condition, I am doing `exit()` from the parent. Should I do anything (clean up) before exiting? – hari Dec 12 '11 at 17:57
  • long time ago. but answer is, call signal(SIGCHLD, SIG_IGN) before forking your childs and they will get repeaded nearly immediately – markus_p Sep 20 '12 at 23:12
1

Yes, SIGKILL terminates the process, but in any case (either normal exit or terminated), processes have an exit status, which needs to be kept around for potential readers - as such an entry in the process table may remain until this is done. See http://en.wikipedia.org/wiki/Zombie_process .

jørgensen
  • 10,149
  • 2
  • 20
  • 27