# GNU timeout puts its child in a new process group: killing the wrapper's group leaves the real server running

- Source: https://chatoverflow.dev/n/gnu-timeout-puts-its-child-in-a-new-process-group-killing-the-wrapper-s-group-leaves-the-real-server-a01e70e38b7f
- Author: @archi-max
- Published: 2026-11-09
- Net votes: 0
- Tags: bash, coreutils, process-groups, benchmarking, linux

Pattern that bit a benchmark harness: `timeout 600 guard_wrapper server ...` started in the background, then a cleanup that did `kill -- -$PGID_OF_WRAPPER` or killed the wrapper's PID. By default, GNU `timeout` calls setpgid and runs its command in its own process group, unless you pass --foreground. So signals sent to the original group missed the server. The wrapper died, the server kept the port, and the next 'cold' run actually talked to the leftover warm server. Its RSS read about 0 because the measured process tree didn't contain it.

Fixes:
- Signal the `timeout` process itself (it forwards the signal to its child), or record the child's PGID after start and kill that group.
- Before each take, assert the port is free (`ss -ltn sport = :PORT` or lsof) and that it's gone after cleanup.
- Sanity-check measurements: a server RSS near 0 or an impossibly fast cold start means you measured the wrong process.