Apple Feedback Assistant has now accepted the report as *FB25248676*, titled “macOS 27.0.1: concurrent parent/child setpgid calls intermittently return EPERM”. The submitted package includes both C reproducers and the measured results from my earlier email.
This is a submission reference; Apple has not yet provided a diagnosis or fix. Thanks, Leonid On Mon, 19 Oct 2026 14:51:16 +0000, Leonid Komarovsky < [email protected]> wrote: Hello, I'm seeing an intermittent diagnostic in interactive Bash 5.3.20 on macOS 27.0.1: -bash: child setpgid (64828 to 64828): Operation not permitted It first appeared when opening an iTerm2 session. A clean interactive Bash launched with --noprofile --norc also reproduced it while executing a simple external command, so the startup files are not necessary. Two standalone C reproducers reproduce the underlying behavior without Bash. The parent calls setpgid(child_pid, child_pid), while the child calls setpgid(0, 0) or the equivalent explicit-PID request. If the calls overlap, one can fail with EPERM while the other succeeds and the final PGID is correct. Serialized calls did not fail in these tests. The independently written direct-system-call reproducer uses syscall(SYS_setpgid, ...) and gave these results: concurrent, 2000 iterations: 5 parent EPERM errors, 26 child EPERM errors parent-first, 1000 iterations: 0 errors child-first, 1000 iterations: 0 errors child-only, 1000 iterations: 0 errors There were no other errno values, no iterations where both requests failed, no incorrect final process groups, and no observed session changes. The child stays alive until the parent has read the result and checked its PGID. Neither reproducer calls exec or setsid; the child is not a session leader. errno is saved immediately after the call. An independent wrapper-based reproducer run directly in iTerm2 gave 6 parent and 12 child EPERM errors in 1000 concurrent iterations, versus zero errors in 1000 parent-then-child iterations. Tracing a real Bash occurrence also showed the parent succeeding and the child receiving EPERM with the correct resulting PGID. Environment: GNU Bash 5.3.20, Homebrew build macOS 27.0.1 (26A434), Darwin 27.0.0, XNU 13432.1.9~1 arm64, hardware model Mac17,6 Apple clang 21.0.0 (clang-2100.3.34.2) Target: arm64-apple-darwin27.0.0 Tests: October 18-19, 2026 Build and run the attached direct-system-call reproducer: xcrun clang -O2 -Wno-deprecated-declarations setpgid-direct-syscall-audit.c -o setpgid-audit ./setpgid-audit concurrent 2000 ./setpgid-audit parent-first 1000 ./setpgid-audit child-first 1000 ./setpgid-audit child-only 1000 An independent macOS report and application-specific mitigation are here: https://github.com/scholay/xsime/issues/81 https://github.com/scholay/xsime/commit/07c59c86c63854d1b1f69d018259d9270af11aae The pure-C reproduction points to behavior below Bash, which I am also taking to Apple. I'm notifying this list because of the user-visible diagnostic and to ask whether Bash should verify that the requested PGID was established before reporting this particular failure. I am not proposing that Bash ignore EPERM generally, and I have not established the exact kernel defect or the macOS version that introduced it. Both C sources and the measured results are attached. No workaround or shell-configuration change has been installed. Thanks, Leonid
