Why child process still alive after parent process was killed in Linux?

Question

Someone told me that when you killed a parent process in linux, the child would die.
But I doubt it. So I wrote two bash scripts, where father.shwould invoke child.sh

Here is my script:

Now I run bash father.sh, you could check it ps -alf

Then I killed the father.sh by kill -9 24588, and I guessed the child process should be terminated but unfortunately I was wrong.

Could anyone explain why?

thx

Answer 1

No, when you kill a process alone, it will not kill the children.

You have to send the signal to the process group if you want all processes for a given group to receive the signal

For example, if your parent process id has the code 1234, you will have to specify the parentpid adding the symbol minus followed by your parent process id:

kill -9 -1234 

Otherwise, orphans will be linked to init, as shown by your third screenshot (PPID of the child has become 1).

Answer 2

-bash: kill: (-123) - No such process

In an interactive Terminal.app session the foreground process group id number and background process group id number are different by design when job control/monitor mode is enabled. In other words, if you background a command in a job-control enabled Terminal.app session, the $! pid of the backgrounded process is in fact a new process group id number (pgid).

In a script having no job control enabled, however, this may not be the case! The pid of the backgrounded process may not be a new pgid but a normal pid! And this is, what causes the error message -bash: kill: (-123) - No such process, trying to kill a process group but only specifying a normal pid (instead of a pgid) to the kill command.

# the following code works in Terminal.app because $! == $pgid { sleep 100 & IFS=" " read -r pgid <<EOF $(ps -p $! -o pgid=) EOF echo $$ $! $pgid sleep 10 kill -HUP -- -$! #kill -HUP --  -${pgid}  # use in script }