Shell: deferring TERM around `cmd & PID=$!` still leaks the child; the forked child keeps the deferral trap until exec
Setup: a build script runs a compiler in the background with setsid (setsid nice cc ... & CC=$!) and has a TERM trap that kills the compiler's session (kill -s TERM -- -$CC || kill $CC). A TERM that lands between & and CC=$! runs the trap with an empty CC, so the compiler keeps running.
The obvious fix isn't enough: install a note-only trap (trap 'STOPPED=1' TERM) before the launch, then after CC=$! put the real trap back and act if STOPPED is set. Under 3 concurrent test loops it still leaked in 8 of 24 runs (macOS bash 3.2 as sh; similar on Linux). The cause: the forked child keeps the parent's note-only trap until it execs. If the parent's kill $CC lands in that window (the child hasn't called setsid yet, so kill -- -$CC fails), the child just sets STOPPED=1 in its own copy, then execs the compiler.
What worked: if the session kill fails, send KILL to the pid (it can't be trapped, and before exec and setsid there are no grandchildren yet), then TERM the session again in case setsid ran in between: kill -s TERM -- "-$CC" 2>/dev/null || { kill -s KILL "$CC"; kill -s TERM -- "-$CC"; } 2>/dev/null. Result: 0 leaks in 48 stressed runs on macOS, and 0 of 8 on Linux, where the old script leaked 8 of 8.
How to hit the microsecond window deterministically in a test: run the script with bash and set BASH_ENV to a file containing trap '[ "$BASH_COMMAND" = "CC=\$!" ] && [ "${BASHPID:-$$}" = "$$" ] && { : > "$MARK"; kill -TERM $$; }' DEBUG. Non-interactive bash sources BASH_ENV, so the DEBUG trap fires right before CC=$! runs. Check that the mark exists, so the test isn't vacuous. This only works when the script runs as bash: bash invoked as sh ignores BASH_ENV, and so does dash.
Reproduced on Linux with your BASH_ENV DEBUG trick, and the result depends on the bash version. Script: note-only trap 'STOPPED=1' TERM, 'setsid sleep 47.N & CC=$!', real trap 'kill -s TERM -- -$CC || kill $CC', then the STOPPED check. Three concurrent loops x 40 runs per shell, the mark was hit in every run, leak = 'sleep 47.N' still alive 0.1 s after the script exited. Old fallback ('|| kill $CC'): bash 3.2.57 leaked 43/120, bash 4.4.18 74/120, bash 5.1.16 0/120, bash 5.2.21 0/120. The session kill failed in nearly every run on all four (instrumented: 'kill -- -$CC' failed in 119 or 120 of 120), so on 5.1+ the plain 'kill $CC' was enough here. Your fix ('|| { kill -s KILL "$CC"; kill -s TERM -- "-$CC"; }'): 0/120 leaks on all four versions. Harness gotcha if you repeat this: capturing the script's output with $(...) hides the leak, because the leaked sleep keeps the capture pipe open, so $(...) returns only when the sleep exits and pgrep then finds nothing. Redirect to a file instead.