Re: Kill sends signal to wrong process group with job control enabled

On 01/03/2026 08:47, Robert Elz wrote:
>      Date:        Sun, 1 Mar 2026 06:33:40 -0800
>      From:        Ben Ashton <[email protected]>
>      Message-ID:  <[email protected]>
> 
>    | It's unrelated, but I'm curious what systems don't make the PGID the
>    | same as the PID of the leader? I thought that was a POSIX thing.
> 
> No.   It is related to how pipelines are forked in the shell,   To make
> a new process group:
> 
>    | The  FreeBSD syscall manual for "setsid" states: "the setsid() system call
>    | returns the value of the process group ID of the new process group,
>    | which is the same� as�the� process� ID of the calling process."
> 
> that is absolutely correct.   So it all depends how the processes
> of a pipeline are forked (for anything other than a pipeline it makes
> no difference, the shell forks once, that becomes the process group leader,
> and its pid is $!).
> 
> It used to be the case once that the shell would fork once for pipelines
> as well, and then that process would be both $! and the process group leader,
> and because of posix rules, it would also become the rightmost process of
> the pipeline, forking children for the other processes for the rest of the
> pipe.   But while not impossible, it is difficult, and defeats some
> optimisations, to implement things that way on a system supporting the
> pipefail option, which is required by POSIX now.
> 
> So, instead the parent shell (the one which is going to set $!) forks all
> of the children, and adds each of them to the new process group.   To do
> that it needs to know the process group ID as each child is created (there's
> no sane way to send the info to a process later, only by the memory copy from
> the fork()).  So the shell forks once, that child creates a new process
> group, the parent knows what that is, as it is the pid of the child it just
> created (which fork()) returns.   Then it forks processes for the rest of
> the pipeline, those processes know the pgrp id, and join that pgrp
> immediately after starting after the fork().
> 
> Now it all depends which order the shell creates the pipeline, for which
> there are 2 rational choices, left to right, or right to left; which is
> simpler depends upon the data structure the shell's parser created when
> it parsed the pipeline.   If the pipeline is created right to left, then
> the pgrp id is the rightmost process (the way it used to be in times past),
> and that also becomes $!.   If the pipeline is created left to right, then
> the pgrp is is the pid of the leftmost process, but $! still needs to be the
> pid of the rightmost process, hence $! and the pgrp ID are different.
> 
> kre
> 
> ps: the NetBSD shell has a builtin command which converts between pids and
> pgrp ids of children of the shell, so scripts can easily do whatever it is
> they really want to achieve, and the shell doesn't need to attempt to guess
> what the script is intending  (-$! is certainly not guaranteed to be the
> pgrp ID of anything, and if it is, it isn't necessarily what you want, so
> when a shell sees that, it has to attempt to intuit what was really meant).
> 
> Sorry, no markup survived my cut&paste from an xterm into my MUA in the
> following:
> 
>       jobid [-g|-j|-p] [job]
>              With no flags, print the process identifiers of the processes in
>              the job.  If the job argument is omitted, the current job is used.
>              Any of the ways to select a job may be used for job, including the
>              '%' forms, or the process id of the job leader ('$!' if the job
>              was created in the background.)
> 
>              If one of the flags is given, then instead of the list of process
>              identifiers, the jobid command prints:
> 
>              -g     the process group, if one was created for this job, or
>                     nothing otherwise (the job is in the same process group as
>                     the shell.)
> 
>              -j     the job identifier (using '%n' notation, where n is a
>                     number) is printed.
> 
>              -p     only the process id of the process group leader is printed.
> 
>              These flags are mutually exclusive.
> 
>              jobid exits with status 2 if there is an argument error, status 1,
>              if with -g the job had no separate process group, or with -p there
>              is no process group leader (should not happen), and otherwise
>              exits with status 0.
> 
> So, "jobid -g $!" produces the process group ID from the $! value.
> 
> Just for completeness, jobs without process group ids of their own
> are ones created when job control is disabled - which is the default
> for scripts.
> 
> 
> 
Thank you for the thorough explanation. Given the issue you describe 
with pipelines, I can see why there are scenarios where the shell might 
want to translate $! so that you can kill the process group of a 
backgrounded job irrespective of the order in which the pipeline is 
composed.

The issue is that within the subshell, backgrounded commands don't 
automatically get their own process groups (despite job control being 
enabled outside of the subshell), however that translation still occurs. 
Inside the subshell running "sleep 5 &" will just create a child process 
that belongs to the process group of the subshell. So that translation 
will result in me killing the process group of the subshell. Surely we 
only want that translation to occur when the shell created a new process 
group for the command?

Thanks to your explanation I was able to simplify the reproduction quite 
a lot. Here is what happens with bash and various other shells:

ben@work-laptop:~$ dash -c 'set -m; (setsid sleep 5 & pid=$!; sleep 2; 
kill -TERM -$pid; echo here)'
here
ben@work-laptop:~$ ash -c 'set -m; (setsid sleep 5 & pid=$!; sleep 2; 
kill -TERM -$pid; echo here)'
here
ben@work-laptop:~$ zsh -c 'set -m; (setsid sleep 5 & pid=$!; sleep 2; 
kill -TERM -$pid; echo here)'
here
ben@work-laptop:~$ bash -c 'set -m; (setsid sleep 5 & pid=$!; sleep 2; 
kill -TERM -$pid; echo here)'
Terminated

As you can see, bash is the only one that translates $! to the PGID of 
the subshell. I confirmed with strace that the other shells ARE killing 
the correct process group.

The reason I previously stated that it doesn't matter how I obtain the 
PGID, is because it's not like the shell is performing any complex logic 
to figure out that the number was derived from $!. I could have used 
some external tool, or read /proc/PID/stat to determine the process 
group that I wanted to kill. The problem is that the PID effectively 
becomes a magic number that will be translated without my knowledge.