Open arifkalayci opened 5 years ago
Interesting! We moved most of our applications off Heroku to Kubernetes awhile ago so we haven't noticed this. Perhaps we could add a configuration option that controls whether the delayed_job_worker_pool master process propagates the SIGTERM to child processes here. Ideally we could default that configuration properly for Heroku environments (the version of the stack might matter here too) vs. non-Heroku environments.
It looks like my worker receives two TERM signals when the Heroku dyno is restarted. Heroku docs says that:
So that's the first signal. I guess the second signal is sent by the master process to the worker. I am doing
Delayed::Worker.raise_signal_exceptions = :term
and rescue fromSignalException
to do some cleanup before exiting. In the case of two signals, the first is handled but the second is gets left unhandled. Any ideas on how to handle this two signals situation?