limitations h12 error desc code change heroku unicorn

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



Unicorn sale de Timeout en Heroku después de atrapar TERM y enviar QUIT (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.

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/ ).