| Subject: | Sequence of signals for the "die" method under Unix |
The Proc::Background man page says for the "die" method:
On Unix, the following signals are sent to the process in one second
intervals until the process dies: HUP, QUIT, INT, KILL.
I wonder why this sequence of signals. First, I would not try HUP as it
does not have a clear meaning in practice, and with some software, this
can have unexpected effects. Indeed when receiving SIGHUP, some
processes (like sshd) re-execute themselves and the PID changes. I
haven't tried, but I fear that Proc::Background can no longer track such
a process (when the PID changes).
The clean way to terminate a process is to send the TERM signal. So, it
should be tried first. Then I would reverse INT and QUIT since QUIT is
stronger than INT, e.g. software such as mutt and svn traps INT (either
to ask for confirmation or to do some clean-up), but not QUIT. I would
even do TERM then KILL directly because:
* this is what processes expect in practice (TERM really means process
termination, while INT and QUIT generally involve user interaction, e.g.
because the user typed Ctrl-C or Ctrl-\ --- now, for a background
process, this doesn't have much sense);
* in practice, TERM is "stronger" than INT, and to avoid the unnecessary
core dump with QUIT;
* this is what is done during a shutdown under Linux, AFAIK.
Also, as clean-up can take time (in particular with svn) and
interrupting it may lead to data corruption, there should be more time
between TERM and the next signal, e.g. one minute.