One of my colleague told me this morning, when he killed supervisord by \"kill -9\", the subprocesses of supervisord is not killed.
He is quite sure about that, but I
You have to make the sub processes daemonic in order to have them killed when the father is killed (or dies), otherwise they are adopted by init(1).
On UNIX, there is no enforced relation between parent and child process's lifetimes. Strictly speaking, process will only terminate when they call exit() or receive an unhandled signal for which default action is to terminate.
However, an entire "foreground process group" in a "controlling terminal" can receive signals like SIGINT and SIGQUIT when the user hits ctrl-C, ctrl-\, etc. on that terminal. Specific behaviour is partly implemented by the login shell (with help from the tty driver). Details may be quite complicated: look here and here
No, child processes are not necessarily killed when the parent is killed.
However, if the child has a pipe open which it is writing to and the parent is reading from, it will get a SIGPIPE when it next tries to write to the pipe, for which the default action is to kill it. That is often what happens in practice.
You just need to know which process or service you wanna kill. In my case httpd is.
killall -9 httpd
It will kill all the child processes of httpd.
If u close the terminal pid which is the parent process id of the process then terminal is closed. And when terminal is closed then all its processes also gets killed. But if u create a sub shell in shell then if u create any process and kill ppid of that process then only that sub shell kill and their child becomes orphans. Their parent becomes init and pid is 1.
[trainee@SIPL ~]$ ps -ef | grep sleep trainee 3893 3870 0 10:55 pts/1 00:00:00 sleep 4000 trainee 3895 3788 0 10:55 pts/0 00:00:00 grep --color=auto sleep [trainee@SIPL ~]$ kill -9 3870 [trainee@SIPL ~]$ ps -ef | grep sleep trainee 3893 1 0 10:55 pts/1 00:00:00 sleep 4000 trainee 3906 3788 0 10:55 pts/0 00:00:00 grep --color=auto sleep