Make the signal for child termination configurable

[fxn]

Resque sends SIGTERM to signal the child process it should terminate, but this conflicts with Heroku, which sends SIGTERM to all processes when shutting down dynos. That is, your child receives SIGTERM from Heroku right away and RESQUE_PRE_SHUTDOWN_TIMEOUT is not honored.

The gem resque-heroku-signals addresses this by redefining Resque::Worker#unregister_signal_handlers in a way that makes the SIGTERM signal handler ignore the first occurrence, and raise Resque::TermException on the second one.

However, this solution is partial, really, because Heroku documents it may send you multiple SIGTERMs, and I have confirmed it occasionally does. Therefore, you cannot assume the 2nd signal comes from the worker.

A clean way to solve this would be to tell Resque to use a different signal. I suspect this might be the intention with the existing

attr_accessor :term_child_signal

which seems to be unused as of this writing.

[fxn]

Meanwhile, I have opened resque/resque-heroku-signals#14 to redefine new_kill_child. That version sends SIGINT to the child, instead of SIGTERM. Then, unregister_signal_handlers ignores SIGTERM (coming from Heroku) and raises on SIGINT (coming from the worker).

Heroku is an important part of the Ruby ecosystem, I believe all that monkey patching is a symptom of missing support here.