Re: bash signal trap bug

[Chet Ramey]

On 1/8/14, 12:01 PM, Paweł Gołaszewski wrote:
> Hello,
> 
> I think I've found bug in signal handling in bash.
> 
> Look at 2 scripts:
> http://www.blues.gda.pl/SOURCES/show_logs.sh
> http://www.blues.gda.pl/SOURCES/show_logs.zsh
> 
> Both are identical. "zsh" version works fine, "bash" version doesn't.
> After start everything is fine, a can send _one_ HUP signal and it works 
> as expected. The next HUP simply doesn't work. Even more: INT signal 
> (Ctrl+C) works... like SIGHUP.

There are a few things going on here.  First, after the first SIGHUP, you
are running the entire script from a trap handler.  Bash treats things in
a trap handler context a little specially.

Second, bash doesn't allow recursive trap invocations: it blocks the signal
for which the trap is being run while the trap command is being executed,
as if you were running a signal handler.  That's why the second SIGHUP has
no apparent effect.

Also, bash doesn't set the flag that a signal is no longer pending until
after it executes the trap command.  This means that the flag is still set
for SIGHUP (signal 1) (because you're running from the trap handler) when
the SIGINT (signal 2) arrives and is processed.  Bash processes signals in
order, and so attempts to execute the trap commands for SIGHUP before
SIGINT. That's why SIGINT appears to act like SIGHUP. (This is arguably a
bug.)

I have made several changes to the trap command processing, and things
in bash-4.3 should be closer to the way you want them to run.  However,
there is enough variation in how different shells handle this situation
(bash, ksh93, dash, and zsh all act differently) that there's no consensus
on exactly what's "right".

Chet
-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/