AFAIK this problem is endemic to any job processing system where jobs can take more than N seconds to process. What Heroku does:
* Heroku sends the TERM signal.
* The process has 10 seconds to exit itself.
* After 10 seconds, the KILL signal is sent to terminate the process without notice.
Sidekiq does this:
* Upon TERM, the job fetcher thread is halted immediately so no more work is started.
* Sidekiq waits 8 seconds for any busy Processors to finish their job.
* After 8 seconds, Sidekiq::Shutdown is raised on each busy Processor. The corresponding jobs are pushed back to Redis so they can be restarted later. This must be done within 2 seconds.
* Sidekiq exits or is KILLed.
+1 on that question, I'd be very interested in that as well. My guess would be that since Sidekiq is thread-based rather than process-based it wouldn't have to deal with the issue of all processes receiving the signal at the same time.