bug-bash
[Top][All Lists]
Advanced

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

Re: "wait" loses signals


From: Denys Vlasenko
Subject: Re: "wait" loses signals
Date: Fri, 21 Feb 2020 15:44:37 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0

On 2/20/20 4:27 PM, Chet Ramey wrote:
On 2/20/20 3:02 AM, Denys Vlasenko wrote:
On 2/19/20 9:30 PM, Chet Ramey wrote:
On 2/19/20 5:29 AM, Denys Vlasenko wrote:
A bug report from Harald van Dijk:

test2.sh:
trap 'kill $!; exit' TERM
{ kill $$; exec sleep 9; } &
wait $!

The above script ought exit quickly, and not leave a stray
"sleep" child:
(1) if "kill $$" signal is delivered before "wait",
then TERM trap will kill the child, and exit.

This strikes me as a shaky assumption, dependent on when the shell receives
the SIGTERM and when it runs traps.

The undisputable fact is that after shell forks a child
to run the "{...} &" subshell, it will receive the SIGTERM signal.

And since it has a trap for it, it should be run.

(There's nothing in POSIX that says
when pending traps are processed. Bash runs them after commands.)

Yes, and here we are "after command", specifically after "{...} &" command.
Since we got a trapped signal, we must run its trap.

Did you look at the scenario in my message?

What scenario?

As I said, there are just two possibilities:
signal is received before the point when shell checks for received
signals after "{...} &" command;
or signal is received after that point, and thus signal is
considered to be received "inside wait builtin".

In both cases, trap should be run.

Keep in mind that you can't run the trap out of the signal handler.

Yes, running anything remotely complex out of signal handlers is
a bad idea: signals can arrive somewhere in the middle of stdio, or memory 
allocation,
or something similarly critical. Reentering one of those can deadlock.

Properly-written programs are careful to record
signal reception in a flag variable, or a pipe, etc,
then return from signal handler, and act on it later, not in a signal handler.




reply via email to

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