Difference between SIGKILL SIGTERM considering process tree

Question

What is the difference between SIGTERM and SIGKILL when it comes to the process tree?
When a root thread recieves SIGKILL does it get killed cleanly or does it leave it's child threads as zombies?
Is there any signal which can be sent to a root thread to cleanly exit by not leaving any zombie threads ?

Thanks.

Answer 1

If you kill the root process (parent process), this should make orphan children, not zombie children. orphan children are made when you kill a process's parent, and the kernel makes init the parent of orphans. init is supposed to wait until orphan dies, then use wait to clean it up.

Zombie children are created when a process (not its parent) ends and its parent does not take up its exit status from the process table.

It sounds to me like you are worried about leaving orphans because by definition, when you kill a zombies parent process, the zombie child itself dies.

To kill your orphans, use kill -9 , which is the equivalent SIGKILL.

Here is a more in depth tutorial for killing stuff on linux: http://riccomini.name/posts/linux/2012-09-25-kill-subprocesses-linux-bash/

Answer 2

You can't control that by signal; only its parent process can control that, by calling waitpid() or setting signal handlers for SIGCHLD. See SIGCHLD and SA_NOCLDWAIT in the sigaction(2) manpage for details.

Also, what happens to child threads depends on the Linux kernel version. With 2.6's POSIX threads, killing the main thread should cause the other threads to exit cleanly. With 2.4 LinuxThreads, each thread is actually a separate process and SIGKILL doesn't give the root thread a chance to tell the others to shut down, whereas SIGTERM does.