On 3/3/26 15:59, Chet Ramey wrote:
On 3/1/26 2:52 PM, Daniel Villeneuve wrote:
Hi,
I'm using GNU bash, version 5.1.8(1)-release
(x86_64-redhat-linux-gnu),
on a CentOS Stream 9 machine.
I am unable to understand what I consider an unexpected behavior
from a
bash script that does the following:
- use "set -e"
- install an EXIT trap that takes some time to execute
- install a TERM trap that just echoes and then re-kills the
script
with TERM
- start a "sleep infinity" process
Both traps unset traps for EXIT and TERM on entry.
On reboot, the TERM signal is not caught immediately because of
the
"sleep" subprocess, which
is killed and returns an error. Bash then could start the EXIT
trap or
handle the TERM signal.
What I observe is that it "starts" the EXIT trap but is then
immediately interrupted by the TERM signal.
It probably runs the EXIT trap due to the SIGHUP, which is not
included
in your testing. I didn't test anything, just looked at the strace
output.
wait4(-1, [{WIFSIGNALED(s) && WTERMSIG(s) == SIGTERM}], 0, NULL)
= 3130
--- SIGHUP {si_signo=SIGHUP, si_code=SI_USER, si_pid=1,
si_uid=0} ---
--- SIGCONT {si_signo=SIGCONT, si_code=SI_USER, si_pid=1,
si_uid=0} ---
rt_sigreturn({mask=[CHLD]}) = 3130
--- SIGTERM {si_signo=SIGTERM, si_code=SI_USER, si_pid=1,
si_uid=0} ---
Thanks for looking into this.
SIGHUP could explain a different behavior for the reboot case, but I
still
don't see why the following SIGTERM that is sent from the TERM trap and
received (seen in the strace output) does not kill the shell right at
that
moment.
I don't see any sign of SIGTERM being blocked or ignored (from the
strace
output) at the point the shell receives the TERM signal, so how could
the
shell ignore it and continue with the exit trap?
I've just added a line to dump /proc/$$/status just before the re-kill,
and
here is what I get:
SigCgt: 0000000043817efb
The 7 here tells me that SIGTERM (15) is still being caught, despite
the "trap - EXIT TERM" statement. Could that explain why TERM
seems ignored? But this is also the case (7xxx) in normal
"kill process-group" mode, so why the different behavior?
Regards,
--
Daniel Villeneuve
