Long running delayed_job jobs stay locked after a restart on Heroku
Abort Job Cleanly on SIGTERM
A much better solution is now built into delayed_job. Use this setting to throw an exception on TERM signals by adding this in your initializer:
Delayed::Worker.raise_signal_exceptions = :term
With that setting, the job will properly clean up and exit prior to heroku issuing a final KILL signal intended for non-cooperating processes:
You may need to raise exceptions on SIGTERM signals, Delayed::Worker.raise_signal_exceptions = :term will cause the worker to raise a SignalException causing the running job to abort and be unlocked, which makes the job available to other workers. The default for this option is false.
Possible values for raise_signal_exceptions
are:
-
false
- No exceptions will be raised (Default) -
:term
- Will only raise an exception on TERM signals but INT will wait for the current job to finish. -
true
- Will raise an exception on TERM and INT
Available since Version 3.0.5.
See this commit where it was introduced.
TLDR:
Put this at the top of your job method:
begin
term_now = false
old_term_handler = trap 'TERM' do
term_now = true
old_term_handler.call
end
AND
Make sure this is called at least once every ten seconds:
if term_now
puts 'told to terminate'
return true
end
AND
At the end of your method, put this:
ensure
trap 'TERM', old_term_handler
end
Explanation:
I was having the same problem and came upon this Heroku article.
The job contained an outer loop, so I followed the article and added a trap('TERM')
and exit
. However delayed_job
picks that up as failed with SystemExit
and marks the task as failed.
With the SIGTERM
now trapped by our trap
the worker's handler isn't called and instead it immediately restarts the job and then gets SIGKILL
a few seconds later. Back to square one.
I tried a few alternatives to exit
:
A
return true
marks the job as successful (and removes it from the queue), but suffers from the same problem if there's another job waiting in the queue.Calling
exit!
will successfully exit the job and the worker, but it doesn't allow the worker to remove the job from the queue, so you still have the 'orphaned locked jobs' problem.
My final solution was the one given at at the top of my answer, it comprises of three parts:
-
Before we start the potentially long job we add a new interrupt handler for
'TERM'
by doing atrap
(as described in the Heroku article), and we use it to setterm_now = true
.But we must also grab the
old_term_handler
which the delayed job worker code set (which is returned bytrap
) and remember tocall
it. -
We still must ensure that we return control to
Delayed:Job:Worker
with sufficient time for it to clean up and shutdown, so we should checkterm_now
at least (just under) every ten seconds andreturn
if it istrue
.You can either
return true
orreturn false
depending on whether you want the job to be considered successful or not. Finally it is vital to remember to remove your handler and install back the
Delayed:Job:Worker
one when you have finished. If you fail to do this you will keep a dangling reference to the one we added, which can result in a memory leak if you add another one on top of that (for example, when the worker starts this job again).
New to the site, so can't comment on Dave's post, and need to add a new answer.
The issue I have with Dave's approach is that my tasks are long (minutes up to 8 hours), and are not repetitive at all. I can't "ensure to call" every 10 seconds. Also, I have tried Dave's answer, and the job is always removed from the queue, regardless of what I return -- true or false. I am unclear as to how to keep the job on the queue.
See this this pull request. I think this may work for me. Please feel free to comment on it and support the pull request.
I am currently experimenting with a trap then rescue the exit signal... No luck so far.