Re: [Help-bash] How to trap SIGTERM?

[Pierre Gaston]

On Mon, Apr 22, 2013 at 1:46 AM, Chet Ramey <address@hidden> wrote:

On 4/20/13 4:18 AM, Pierre Gaston wrote:

> $ for i in 2  15;do ./sigtest $i;done
> Child exit normally: 0
> Child exited with status: 15 and signal: 15
>
> I'm not quite sure why the shell doesn't indicate that it was killed with INT.

It comes back to the Cracauer article Bob referenced.  See comments at the
end.

> The same happens with the EXIT trap:
>
> #!/usr/bin/env bash
> trap "echo Booh!" EXIT
> sleep 5
>
> $ for i in 2  15;do ./sigtest $i;done
> booh!
> Child exit normally: 0
> booh!
> Child exited with status: 15 and signal: 15
>
>  so the trap is indeed not affecting TERM.
> INT is not simply ignored (like QUIT is) because if I reset the trap, running:
>
> #!/usr/bin/env bash
> trap "echo booh!" EXIT
> trap "echo INT;trap - INT;kill -INT $$" INT
> sleep 5
>
> I get:
>
> $ for i in 2  15;do ./sigtest $i;done
> INT
> booh!
> Child exited with status: 2 and signal: 2
> booh!
> Child exited with status: 15 and signal: 15
>
> So resetting the trap seems to do what I would expect, the shell exits
> indicating that it has been killed with INT.
>
> The shell is doing some strange handling, if I change the script to:
>
> #!/usr/bin/env bash
> trap "echo booh!" EXIT
> sleep 5  & wait $!
>
> I get:
>
> $ for i in 2  15;do ./sigtest $i;done
> booh!
> Child exit normally: 129
> booh!
> Child exited with status: 15 and signal: 15
>
> As I said I'm not sure what are the rationale behind all that.

It can be found in the article.  Sending SIGINT from a program to just the
shell is somewhat artificial, since a keyboard-generated SIGINT goes to the
process group.  When the shell is not interactive, as it is in this case,
the shell assumes that the SIGINT was sent from the keyboard and received
by the foreground process group.  It uses the child's exit status as a
guide for signal disposition: if the child exits due to SIGINT, the shell
acts as if it received the SIGINT; if not, the shell effectively ignores
the signal.

I see thanks, so if I press C-c instead sleep would (or at least should) indictates it

has exited due to sigint and as a result the script would do so also and all is ok.

The shell also assumes that if there is a trap set on SIGINT, that the
programmer must want to know about keyboard-generated signals whether or
not the foreground process responds to them, and runs the trap handler.
This is a heuristic that's worked out pretty well so far.

Running the sleep in the background and the wait in the foreground is also
documented in the section you originally quoted from the manual page.

I see, somehow I was expecting 128+2 instead of 129

 

SIGTERM, however, since it is not generated from the keyboard and not sent
by default to the terminal's foreground process group, is treated
differently.

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