|Subject:||Re: [Help-bash] How to trap SIGTERM?|
|Date:||Sun, 21 Apr 2013 08:17:10 +0300|
Pierre Gaston wrote:
> Bob Proulx wrote:For what trapped signal would you not need to do this? If you don't
> > 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?
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.
How is SIGTERM any different from SIGHUP, SIGINT or SIGQUIT? Many
> 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?
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.
?? Bash is setting some status? I don't understand. What status is
> I don't think bash does something special with it besides perhaps
> setting the status.
bash setting? Please say more.
A daemon would already have a parent PID of 1. The init process 1
> Would it not be reasonable for a script or any program (for instance
> a daemon) to exit normally after a sigterm?
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.
Please read this reference:
> 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.
I will list that as required reading concerning this topic. :-)
I am going to acknowledge it but no time to look at it in detail at
> 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
> I ran the following test program in C:
the moment. I hope to look at it and then comment.
|[Prev in Thread]||Current Thread||[Next in Thread]|