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/
OpenPGP_signature.asc
Description: OpenPGP digital signature
