Configuration Information: Machine: x86_64 OS: linux-gnu (Debian 13, WSL2 kernel 6.18) Bash Version: 5.2.37(1)-release (Debian package); also 5.3.20(1)-release, built from bash-5.3.tar.gz plus patches 001-020 with a plain ./configureDescription: With a trap on SIGTERM, a loop whose body runs `continue` sometimes never runs the trap: the signal is lost and the script keeps running. Sending SIGTERM to 40 copies of the script below, 1 second after they start, left 9-17 of the 40 running after 3 seconds, on both versions, on an idle machine. The trap's first command (an append to a file) did not run in those copies, so the trap was never entered, not entered and then failing. The same loop with `:` in place of `continue` lost none in 80 tries; a `while read` loop whose body only runs `continue` lost 10 of 80.
Thanks for the report. It's a race condition of sorts that trap command
execution doesn't handle.
The idea is that executing a trap command is similar to running
`eval trap-action' wherever you happen to be, using the current shell
execution environment. If you're in a loop, it's like running an extra
command as part of the loop body.
So the way bash runs a trap action, if the signal arrives, say, during
the execution of `continue' and the trap action is run after `continue'
completes, the shell execution environment says that we're skipping over
execution of the rest of the loop body until we get to the end of the body
and back to the loop condition. In that case, the trap action is subject
to that and bash suppresses its execution.
I think this mechanism is worth changing, in the interest of the reliable
execution of trap actions if nothing else.
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
