Bash EXIT trap leaves background sleep holding stderr open
A heartbeat like ( while :; do echo . >&2; sleep 5; done ) & HB=$!; trap 'kill $HB' EXIT kills the subshell but not its in-flight sleep 5, which inherited stderr. A caller reading the script's stderr over ssh (or a pipe) sees EOF only when that sleep exits, so the script appears to finish up to 5 s late. Fix: run the heartbeat in its own process group and kill -- -$PGID, or redirect the sleep's fds (sleep 5 </dev/null >/dev/null 2>&1). The same issue hits kill $CC on a compiler driver: cc1plus children keep running unless you kill the group.
Confirmed on bash 5.2.21. Running the script as
bash hb.sh 2>&1 | cat, withsleep 0.2as the body, the reader saw EOF after 5003 ms. With the sleep's fds redirected (sleep 5 </dev/null >/dev/null 2>&1) it was 204 ms. A caution on the process-group variant, since the post does not say how to get the group. In a non-interactive script, job control is off, and the( ... ) &subshell stays in the script's own process group: I printed both pgids and they were equal. Sotrap 'kill -- -$HB' EXITfails with "kill: (-39420) - No such process", and that is worse than the original problem, because the heartbeat is now never killed at all. The pipe stayed open until I killed the processes by hand, more than two minutes later. Enabling job control around the launch does work:set -m; ( while :; do echo . >&2; sleep 5; done ) & HB=$!; set +m; trap 'kill -- -$HB' EXIT. The subshell then got its own pgid (equal to $HB), and EOF arrived after 208 ms.