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

On 3/2/26 10:36 AM, Robert Elz wrote:
>      Date:        Mon, 2 Mar 2026 02:32:32 -0800
>      From:        Ben Ashton <[email protected]>
>      Message-ID:  <[email protected]>
> 
>    | That IS what's going on. Setsid makes sleep the leader of a new process
>    | group.
> 
> Yes, but bash doesn't know that, we know what the setsid command is
> intended to do, bash doesn't.

This is true, bash does not really contemplate a job control scenario where
it's not controlling (sic) all of the process groups.

> 
>    | Runing this script:
>    |
>    |    #!/usr/bin/env bash
>    |    set -m
>    |    (
>    |      setsid sleep 40 &
> 
> Imagine what happens here, in the far more common case where the
> setsid is not present, and the command is just "sleep 40 &"

And the process group remains as the shell set it.

>    |      pid=$!
>    |      echo "Sleep pid: $pid"
>    |      sleep 20
>    |      kill -TERM -$pid
>    |      echo "Here"
>    |    )
> 
> And the rest of that is all unchanged.   When bash sees the
> 
> 	kill -TERM -17585
> 
> it can tell you are trying to kill a process group and the process
> group associated with process 17585 which it sees in the job table
> as one if its child processes. 

Correct, bash knows that a child process with that pid exists and knows
what pgrp it assigned to that process.

>  In its job table (which bash provides
> no way I know of to interrogate, but you would be able to see if it had
> the jobid builtin added - perhaps one of the people who knows how to
> create loadable builtins for bash might care to create one for it,

I wrote one a couple of months ago, using the NetBSD description as a
model.

> This is what I meant by the shell attempting to intuit what the
> script intends, and since use of setsid() in scripts I would
> expect is extremely rare, it is probably right more often than
> it is wrong

This is the first time this combination of non-interactive job control
and setsid has been reported, and, as you noted, you can use /bin/kill
instead.

> ps: there is also no requirement that job control be turned off in
> subshell environments, some shells (like bash apparently) do so,

It makes it easier to treat all the processes in the subshell as a single
unit, so, for instance, you can stop and restart a foreground () subshell
and be fairly certain that all the processes receive SIGTSTP/SIGSTOP/
SIGCONT.

> others do not (dash doesn't, nor does ksh93).  In those other shells,
> the setsid(2) does nothing (fails) -- NetBSD has setsid(1) command, so I
> needed to make one - my version just errors and exits if the setsid() sys
> call fails, which it does with dash, ksh93, and the NetBSD sh (another
> ash descendant, like dash) when the "set -m" is there.

Probably because setsid(2) will fail when the process is already a process
group leader.

Chet
-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    [email protected]    http://tiswww.cwru.edu/~chet/

-----BEGIN PGP SIGNATURE-----

wmMEABEIACMWIQR8ATX7CIqvbGbGULm7WGnwZOp0qwUCaaYL3QUDAAAAAAAKCRC7WGnwZOp0q/t7
AJ42RmLtTBcuCPHn1u9fv0J7dOTxHgCfRMONnQNVo4OBGlthvJrdxcqevOI=
=XHJ0
-----END PGP SIGNATURE-----