90 votes

Délai d’attente de sortie Licorne sur Heroku après piégeage à terme et en envoyant QUIT

Je reçois R12 Sortie des erreurs de Délai d'attente pour un Heroku application de la licorne et sidekiq. Ces erreurs se produisent 1-2 fois par jour et chaque fois que je le déployer. Je comprends que j'ai besoin de convertir les signaux d'arrêt de Heroku pour licorne à répondre correctement, mais pensé que je l'avais fait dans le dessous de la licorne config:

worker_processes 3
timeout 30
preload_app true

before_fork do |server, worker|
  Signal.trap 'TERM' do
    puts "Unicorn master intercepting TERM and sending myself QUIT instead. My PID is #{Process.pid}"
    Process.kill 'QUIT', Process.pid
  end

  if defined?(ActiveRecord::Base)
    ActiveRecord::Base.connection.disconnect!
    Rails.logger.info('Disconnected from ActiveRecord')
  end
end

after_fork do |server, worker|
  Signal.trap 'TERM' do
    puts "Unicorn worker intercepting TERM and doing nothing. Wait for master to sent QUIT. My PID is #{Process.pid}"
  end

  if defined?(ActiveRecord::Base)
    ActiveRecord::Base.establish_connection
    Rails.logger.info('Connected to ActiveRecord')
  end

  Sidekiq.configure_client do |config|
    config.redis = { :size => 1 }
  end
end

Mes journaux entourant l'erreur ressembler à ceci:

Stopping all processes with SIGTERM
Unicorn worker intercepting TERM and doing nothing. Wait for master to sent QUIT. My PID is 7
Unicorn worker intercepting TERM and doing nothing. Wait for master to sent QUIT. My PID is 11
Unicorn worker intercepting TERM and doing nothing. Wait for master to sent QUIT. My PID is 15
Unicorn master intercepting TERM and sending myself QUIT instead. My PID is 2
Started GET "/manage"
reaped #<Process::Status: pid 11 exit 0> worker=1
reaped #<Process::Status: pid 7 exit 0> worker=0
reaped #<Process::Status: pid 15 exit 0> worker=2
master complete
Error R12 (Exit timeout) -> At least one process failed to exit within 10 seconds of SIGTERM
Stopping remaining processes with SIGKILL
Process exited with status 137

Il semble que tous les processus enfants ont été récolté avant l'expiration du délai. Est-il possible que le maître est toujours en vie? Aussi, si le routeur être l'envoi de requêtes web à la puissance lors de l'arrêter, comme indiqué dans les logs?

FWIW, je suis en utilisant Heroku zéro temps d'arrêt de déploiement de greffon (https://devcenter.heroku.com/articles/labs-preboot/).

4voto

Winfield Points 10838

Je pense que votre personnalisé de traitement de signal est-ce qui cause des délais d'attente ici.

EDIT: je suis downvoted pour en désaccord avec Heroku de la documentation et j'aimerais remédier à ce problème.

La configuration de votre Licorne application pour les attraper et de les avaler la DURÉE du signal est la cause la plus probable de votre retrait de l'application et non pas fermé correctement.

Heroku semble plaider que la capture et la transformation d'un TERME de signal dans une QUITTER le signal est le bon comportement à son tour une dur de l'arrêt dans un arrêt normal de.

Cependant, cela semble introduire le risque d'absence d'arrêt à tous, dans certains cas, à la racine de ce bug. Les utilisateurs éprouvent de la pendaison des dynamomètres de l'exécution de la Licorne doit examiner la preuve et de prendre leur propre décision basée sur des principes premiers, et pas seulement de la documentation.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X