Handling SIGCHLD

[gazeet]

I have several old bash scripts, that include traps for SIGCHLD. The intention was to catch failures or interrupts in user commands executed within these scripts, allowing the whole script to abort immediately. In Mageia 7 (5.10.46-desktop-1.mga7), for example, this seems to have had the intended effect. Now with kernel 6.5.13-desktop-6.mga9 it seems like SIGCHLD is generated even on normal terminations of child processes.

Reading the description it seems like this might be the expected posix behaviour (but it breaks this previous *simple* use of SigCHLD to try to capture user interrupts during a child process). While I can see how to solve this by elimintating the "trap" and recoding all the user programs that are executed within the scripts to ensure they return the proper exit codes I am curious to know why this behaviour changed with the newer kernels? Is there some kernel setting controlling this?

[doktor5000]

Might be helpful if you would add some actual examples, and some context information - like in what context are those bash scripts run, inside of an interactive shell or not ...
Also what have you configured regarding job control for your bash settings or in your scripts ?

See e.g. https://stackoverflow.com/questions/676 ... ap-sigchld
or also https://forums.raspberrypi.com/viewtopic.php?t=268860
And here from the bash maintainer: https://lists.gnu.org/archive/html/bug- ... 00065.html

On a related note, usually it should be enough to simply trap SIGINT (e.g. when a user presses Ctrl+C during runtime) in the main script, why do it for every child process ?