Supervisión del paquete exec unicorn_rails con bluepill

Question

Debido a unicorn_rails quejándose de diferentes versiones de gemas, pasamos a ejecutar bundle exec unicorn_rails ... en nuestros archivos bluepill. Este cambio se resolvió el problema particular y cosas de arranque y parada, pero cuando tratamos de estado bluepill sudo que ahora recibe

unicornio (pix: XXXXXX): sin control

que se parece a bluepill no está supervisando los procesos unicornio ahora. Reiniciará los procesos hijos si los detengo pero no reiniciaré el proceso principal.

He buscado pero no puedo encontrar mucho sobre este tema y esperaba que alguien pudiera arrojar algo de luz sobre él. El archivo de configuración es bluepill

app_dir = "/opt/local/share/httpd/apps/xyz" 
Bluepill.application('xyz', :log_file => "#{app_dir}/current/log/bluepill.log") do |app| 
    app.process('unicorn') do |process| 
    process.pid_file = "#{app_dir}/shared/pids/unicorn.pid" 
    process.working_dir = "#{app_dir}/current" 

    process.stdout = process.stderr = "#{app_dir}/shared/log/unicorn.err.log" 
    process.start_command = "bundle exec unicorn_rails -D -C#{app_dir}/current/config/environments/production/unicorn.rb -E production" 
    process.stop_command = "kill -QUIT {{PID}}" 
    process.restart_command = "kill -USR2 {{PID}}" 

    process.start_grace_time = 8.seconds 
    process.stop_grace_time = 5.seconds 
    process.restart_grace_time = 13.seconds 

    process.monitor_children do |child_process| 
     child_process.stop_command = "kill -QUIT {{PID}}" 

     child_process.checks :mem_usage, :every => 10.seconds, :below => 200.megabytes, :times => [3,5] 
     child_process.checks :cpu_usage, :every => 10.seconds, :below => 50, :times => [3,5] 
    end 
    end 

end 

Answer 1

Cuando se ejecuta bundle exec, en ella se establece un entorno y el proceso se bifurca unicorn_rails. Bluepill termina supervisando el proceso original bundle exec en lugar de unicornio, por lo que no se supervisa.

puedo configurar mi entorno bundler directamente en bluepill y luego ejecutar unicorn_rails directamente:

Bluepill.application('xyz') do |app| 
    app.environment = `env -i BUNDLE_GEMFILE=#{app_dir}/Gemfile bundle exec env`.lines.inject({}) do |env_hash,l| 
    kv = l.chomp.split('=',2) 
    env_hash[kv[0] = kv[1] 
    env_hash 
    end 

    app.process('unicorn') do |process| 
    process.start_command = "unicorn_rails -D -C#{app_dir}/current/config/environments/production/unicorn.rb -E production" 
    end 
end 

(Nota: He omitido parte del archivo de configuración anterior para mayor claridad su archivo de configuración se ve bien, simplemente trate de añadir el. app.environment cosas arriba y retirar bundle exec de su comando de arranque.)

Esto hace que el ambiente en el bluepill mediante la captura de las variables de entorno bundler utilizando acentos abiertos, al analizar la cadena devuelta en un hash y asignarlo a app.environment.

Answer 2

Sé que esta pregunta es antigua, pero he estado enfrentando este problema durante semanas. Mis sospechas se despertaron cuando me di cuenta de que 'bluepill quit', seguido de volver a cargar la píldora mientras el unicornio se estaba ejecutando, permitieron a bluepill considerar el proceso como "alto".

La respuesta de @ blt04 no ayudó. Hoy llegué a una realización. Mi tiempo de inicio de gracia de 8 segundos no fue suficiente, porque tenía preload_app true en mi configuración de unicornio ... y mi aplicación (rieles) tarda 12 segundos en cargar, no 8.

Aumentando el tiempo de inicio a 30 segundos (salvajemente en exceso de lo que se necesitaba) resolvió el problema. Bluepill simplemente dice 'iniciando' durante 30 segundos, luego sube a 'arriba' correctamente. Unicornio se inicia y se ejecuta de forma normal.

Querrá que el tiempo de reinicio sea más largo de lo necesario para que también se inicie Rails.