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.