-
Notifications
You must be signed in to change notification settings - Fork 11
Signals
Sidekiq responds to several signals. On a Unix machine, you can use the kill
binary or the Process.kill
API in Ruby, e.g.
kill -TTIN pid
Process.kill("TTIN", pid)
Sidekiq will respond to TTIN by printing backtraces for all threads in the process to the logger. This is useful for debugging if you have a Sidekiq process that appears to be dead or stuck.
TSTP tells Sidekiq to "quiet" as it will be shutting down at some point in the near future. It will stop fetching new jobs but continue working on current jobs. Use TSTP + TERM to guarantee shutdown within a time period. Best practice is to send TSTP at the start of a deploy and TERM at the end of a deploy.
Note you still need to send TERM to actually exit the Sidekiq process.
The quiet signal used to be USR1 but was changed to TSTP in Sidekiq 5.0.
Sidekiq <6.0 used USR2 for logfile maintenance. This functionality has been removed in 6.0.
Sidekiq Enterprise uses USR2 as the trigger for a rolling restart.
TERM signals that Sidekiq should shut down within the -t
timeout option given at start-up. It will stop accepting new work, but continue working on current messages (as with TSTP). Any workers that do not finish within the timeout are forcefully terminated and their messages are pushed back to Redis to be executed again when Sidekiq starts up. The timeout defaults to 25 seconds since all Heroku processes must exit within 30 seconds.
The Sidekiq API has helpers to send those signals to processes which are running in an environment where you cannot use signals, e.g. JRuby, Heroku or other environments. For example:
require 'sidekiq/api'
Sidekiq::ProcessSet.new.each(&:quiet!)
The capistrano integration sends TSTP at the very start of the deploy and sends TERM at the end of the deploy in order to give the maximum amount of time for Sidekiq workers to finish their work. Since a Capistrano deploy might take 60 seconds or more, often the timeout defaults are fine because all the workers have finished their current job by the time TERM is signalled.
Home | The Basics | Best Practices | Using Redis | Error Handling | Advanced Options | Problems?
This wiki is tracked by git and publicly editable. You are welcome to fix errors and typos. Any defacing or vandalism of content will result in your changes being reverted and you being blocked.