[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Possible race condition in bash

From: Daniel Colascione
Subject: Re: Possible race condition in bash
Date: Sat, 21 Nov 2020 13:26:46 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0

On 11/21/20 1:15 PM, Chet Ramey wrote:
On 11/21/20 2:32 PM, Andreas Schwab wrote:
On Nov 21 2020, Chet Ramey wrote:

but since the shell always ignores SIGTERM,

Even a non-interactive shell?

No, you're right, it's SIGQUIT the shell always ignores. It catches SIGTERM
if there is an EXIT trap so it can run the trap on EXIT before exiting.

I'd also try it with one of the bash-5.1 testing releases, since I did
some reworking of how the shell handles SIGTERM back in April.

5.1-rc3 has the same issue.

OK, I instrumented bash a little bit, and discovered that the second
child doesn't start running, or at least doesn't get to the point in the
subshell initialization where it resets the signal handlers, until after
the parent sends SIGTERM.

That means the trap handler is still set to catch SIGTERM by the time
the signal arrives. However, the child is not allowed to run the trap
handler; it's supposed to reset the dispositions to the default. This
is the race condition.

It's a dilemma. I could block SIGTERM (all trapped signals, really) until
the child resets the signal dispositions, but that seems like a long time
to keep signals blocked. I'll look at it some more after bash-5.1 is

Plenty of other programs keep signals blocked until reset. I don't see the problem with the delay: if the SIGTERM is ignored, the delay between SIGTERM and kill is infinite. :-) Since the delay between process-kill and actual process death can be arbitrarily long anyway (that's the contract with the kernel), I don't see a problem with the blocking.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]