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

[Pierre Gaston]

On Sun, Apr 21, 2013 at 6:58 AM, Bob Proulx <address@hidden> wrote:

Pierre Gaston wrote:

> Bob Proulx wrote:
> > If you trap a signal then you should not simply "exit".  That rewrites
> > the exit code and hides the kill-on-signal.  Instead you should have
> > the script kill itself.
> >
> >   trap "echo foo 1>&2; trap - TERM; kill -TERM $$" TERM
>
> Do you really need this for TERM also?

For what trapped signal would you not need to do this?  If you don't
trap it then you don't need to do it.  But if you trap it then you
do.  Because you might be writing a trap handler that handles it
intentionally not as an error.

For example Emacs uses C-g to send SIGINT to interrupt the editor as a
normal operating function and does not consider it an error.  If a
script were doing the same then it wouldn't be an error in that case.
Only the script author will know.  But most of the time when people
catch SIGINT and exit it will be an interruption and the proper exit
code will be exiting from the signal.

> I understand this for INT and perhaps QUIT because the a calling
> shell is doing some extra work in this case and kinda need this, but
> it is also true for any existing signal?

How is SIGTERM any different from SIGHUP, SIGINT or SIGQUIT?  Many
daemons catch and handle SIGHUP as a normal operation to go re-read
their configuration file for example.  But of course it keeps running
in that case.

> I don't think bash does something special with it besides perhaps
> setting the status.

??  Bash is setting some status?  I don't understand.  What status is
bash setting?  Please say more.

> Would it not be reasonable for a script or any program (for instance
> a daemon) to exit normally after a sigterm?

A daemon would already have a parent PID of 1.  The init process 1
will always wait for it when it exits but does nothing with the exit
code.  So a daemon's exit code after it has become a daemon is always
discarded and so doesn't matter.  Before the process becomes a daemon
is a different time.  But if a process is killed with SIGTERM before
it can turn into a daemon seems like an interruption to the normal
process flow and it should exit with a signal in that case.

But let's say it is a program that runs in the terminal and just runs
until you interrupt it.  I think it would be fine if it was designed
to catch and ignore SIGINT in that case.  Take 'ping' for example.  It
runs until you interrupt it and upon interruption it catches it and
does exit(0) afterward.  That is fine.  That is one of those exit
codes that I can't imagine anyone ever checks after they type C-c.
But someone might do fancy stuff with PROMPT_COMMAND maybe and so it
might be relevant that way.

> Imo in practice it would make no difference if you resend TERM or not in a
> script, except perhaps if someone wants to investigate how it exits but  in
> this case I would set a trap inside the script.

Please read this reference:

  http://www.cons.org/cracauer/sigint.html

I will list that as required reading concerning this topic.  :-)

> I didn't know this, so I tried to convince myself, and it is true for TERM.
> However I got some strange results with INT...I'm not sure how to interpret
> them.
>
> I ran the following test program in C:

I am going to acknowledge it but no time to look at it in detail at
the moment.  I hope to look at it and then comment.

Bob

I read  your link before and the problem it describes is specifically describing

SIGINT (and SIGQUIT) because that's what C-c sends and because the command running in the foreground in a shell script receives it.

I argue that this use case doesn't happen with TERM, in fact I'm not even sure if  would like a script to abort altogether if I send TERM to the command running in the foreground.

My other point was that not resending TERM is not de facto a "serious problem" as you might want that but you seem to agree with that.

As for bash setting some status, I meant the 128+signal trick that the shell does.