Date: Tue, 7 Jul 2026 19:50:47 +0300
From: Anton <[email protected]>
Message-ID:
<CAJE3=wmtvhexrnjcwjh3nur6xauznpaa30tg5s9zrtzfw1f...@mail.gmail.com>
| I expected that the INT signal would not be propagated to a
| subshell created when calling function `f` asynchronously.
As it should be, and for me, when I tested bash 5.3.15, that is what
happens. So, one of three possibilities I can think of, either you're
running an old bash, which had a bug in this area, in which case you
should upgrade. I actually doubt that is what it would be though, as
this is very basic functionality (shells have ignored SIGINT in background
jobs forever - since before job control, or process groups, as we know
them existed).
Second, your kernel has some bug and is simply broadcasting SIGINT to
all kinds of processes, regardless of whether they are ignoring it or not.
That's also very unlikely.
Third, your testing is messed up, and what is happening is not what you
believe to be happening:
In particular:
| $ sudo strace -p <sleep-pid> -e signal=all
that is a crazy way to test for this, as tracing the process will
reparent it to be a chile of strace, so it can observe what is happening,
and as strace is a foreground process on the current terminal, then
if you send a SIGINT from that terminal, it is no surprise at all that
the sleep would see it.
Try instead sticking "echo sleep done" after the sleep, in f() and see
what happens when you simply run the test, with no debuggers/tracing
involved. Instead of echo, I will use "date" before and after the
sleep:
jacaranda$ cat /tmp/bgf.sh
f()
{
date
sleep 30
date
}
f&
wait
jacaranda$ bash /tmp/bgf.sh
Wed Jul 8 04:08:09 +07 2026
^C
jacaranda$ Wed Jul 8 04:08:39 +07 2026
once more, and this time I will type "date" after the SIGINT is sent:
jacaranda$ bash /tmp/bgf.sh
Wed Jul 8 04:10:45 +07 2026
^C
jacaranda$ date
Wed Jul 8 04:10:47 +07 2026
jacaranda$ Wed Jul 8 04:11:15 +07 2026
Clearly the sleep 30 was not affected by the SIGINT (though the "wait"
in the script was, as it should be).
kre
