-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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 fetching new jobs, but continue working on current jobs (as with TSTP). Any jobs that do not finish within the timeout are forcefully terminated and 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 jobs to finish. Since a Capistrano deploy might take 60 seconds or more, often the timeout defaults are fine because all jobs have finished by the time TERM is signaled.