change - heroku router]: at error code h12 desc request timeout

Unicorn sale de Timeout en Heroku después de atrapar TERM y enviar QUIT

Question

Estoy recibiendo errores de R12 Exit Timeout para una aplicación Heroku que ejecuta unicornio y sidekiq. Estos errores ocurren 1-2 veces al día y cada vez que despliegue. Entiendo que necesito convertir las señales de apagado de Heroku para que el unicornio responda correctamente, pero pensé que lo había hecho en la siguiente configuración de unicornio:

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

Mis registros que rodean el error se ven así:

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

Parece que todos los procesos secundarios se cosecharon con éxito antes del tiempo de espera. ¿Es posible que el maestro todavía esté vivo? Además, ¿debería el enrutador seguir enviando solicitudes web al banco de pruebas durante el cierre, como se muestra en los registros?

FWIW, estoy usando el complemento de despliegue de tiempo de inactividad cero de Heroku ( https://devcenter.heroku.com/articles/labs-preboot/ ).

Answer 1

Creo que su gestión de señal personalizada es lo que está causando los tiempos de espera aquí.

EDITAR: Me están bajando la ley por estar en desacuerdo con la documentación de Heroku y me gustaría abordar esto.

Configurar la aplicación Unicorn para atrapar y tragar la señal TERM es la causa más probable de que la aplicación se cuelgue y no se cierre correctamente.

Heroku parece argumentar que atrapar y transformar una señal TERM en una señal QUIT es el comportamiento correcto para convertir un apagado duro en un apagado elegante.

Sin embargo, hacer esto parece introducir el riesgo de que no se apague en absoluto en algunos casos, la raíz de este error. Los usuarios que experimenten ejecutando dynos ejecutando Unicorn deben considerar la evidencia y tomar su propia decisión basada en los primeros principios, no solo en la documentación.