Re: "wait" loses signals

[Denys Vlasenko]

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.