[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Possible race condition in bash
From: |
Nikolay Borisov |
Subject: |
Re: Possible race condition in bash |
Date: |
Wed, 3 Feb 2021 14:54:30 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 |
On 21.11.20 г. 23:15 ч., 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
> released.
Hello,
Have you had a chance to look into this?
>
> Chet
>
- Re: Possible race condition in bash,
Nikolay Borisov <=