On 2/3/21 7:54 AM, Nikolay Borisov wrote:
Have you had a chance to look into this?
There is a fix in the devel branch.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://ti
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
> i
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
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 be
On Nov 21 2020, Chet Ramey wrote:
> but since the shell always ignores SIGTERM,
Even a non-interactive shell?
> 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.
Andreas.
--
Andr
On 21.11.20 г. 20:50 ч., Chet Ramey wrote:
> On 11/21/20 1:35 PM, Nikolay Borisov wrote:
>
>> I can see setting of SIGTERM handler for both 2 subshells _after_ receiving
>> the signal. What exactly should I be looking at?
>
> That's your race condition.
>
So the kernel initializes the signa
On 21.11.20 г. 20:50 ч., Chet Ramey wrote:
> On 11/21/20 1:35 PM, Nikolay Borisov wrote:
>
>> I can see setting of SIGTERM handler for both 2 subshells _after_ receiving
>> the signal. What exactly should I be looking at?
>
> That's your race condition.
>
But shouldn't the default environme
On 11/21/20 1:35 PM, Nikolay Borisov wrote:
> I can see setting of SIGTERM handler for both 2 subshells _after_ receiving
> the signal. What exactly should I be looking at?
That's your race condition.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa,
On 11/21/20 1:25 PM, Andreas Schwab wrote:
> On Nov 21 2020, Chet Ramey wrote:
>
>> This is a potential race condition, but it's not with the shell.
>
> The race with the trap command in the function is obvious, but that
> should not result in the signal to be ignored. There should always be a
>
On 21.11.20 г. 20:09 ч., Chet Ramey wrote:
> On 11/21/20 3:06 AM, Nikolay Borisov wrote:
>
>> The output is:
>>
>> my pid 12186
>> 12186 subfun xxx 0
>> funpid=12186 twopid=12187 mypid=12185
>> killing 12186 12187
>> waiting on everything
>> my pid 12187
>> 12187 subfun yyy 0
>> received term f
On Nov 21 2020, Chet Ramey wrote:
> This is a potential race condition, but it's not with the shell.
The race with the trap command in the function is obvious, but that
should not result in the signal to be ignored. There should always be a
trap active, either the main one or the one in the func
On 11/21/20 3:06 AM, Nikolay Borisov wrote:
> The output is:
>
> my pid 12186
> 12186 subfun xxx 0
> funpid=12186 twopid=12187 mypid=12185
> killing 12186 12187
> waiting on everything
> my pid 12187
> 12187 subfun yyy 0
> received term for xxx
> 12187 subfun yyy 1
> 12187 subfun yyy 2
> 12187 su
Hello,
It's possible to have the following script never terminate:
#!/bin/bash
subfun() {
trap "echo received term for $*;exit 1" SIGTERM
echo my pid $BASHPID
i=0
while true; do
echo $BASHPID subfun $* $i
i=$((i+1))
sleep 5
done
}
trap 'ec
13 matches
Mail list logo
