Why is the PGID of my child processes not the PID of the parent?

Question

So I keep reading everywhere that this command should terminate all child processes of the parent process:

kill -- -$$

Using a negative ID with the kill command references a PGID and from the examples I have seen it appears the PGID of child processes should be the PID of the parent but its not the case on my system.

On my system the PGID of the child is the same as the PGID of the parent script which turns out to be bash.

What's going on here? Were the examples wrong or is my system set up differently?

What I need to achieve is to terminate child processes without terminating the parent so I don't want to send a kill signal to the PGID the parent is in.

Answer 1

When a process is forked, it inherits its PGID from its parent. The PGID changes when a process becomes a process group leader, then its PGID is copied from its PID. From then on, the new child processes it spawns, and their descendants, inherit that PGID (unless they start new process groups of their own).

In a shell with job control, such as most interactive shells, each job is put in its own process group. If you run a shell script, the shell process running the script will be the group leader, and the PGID will equal its PID.

In a shell without job control, such as most shells used to run scripts, commands are run in the shell's process group.

The syntax kill -- -N kills all the processes in the group with PGID = N. You can't use it with an arbitrary PID, only the PID of a process group leader, since that's the PGID. This is essentially how the shell's

kill %jobid

syntax works -- it internally translates %jobid to the PGID of the job and sends the signal to that PGID.

There's no simple way to run a script in its own process group from another shell script. See How to set process group of a shell script for some suggestions, though.