2011-12-12 14 views
10

El siguiente es el enlace a mi script de inicio para unicornio. https://gist.github.com/1466775El reinicio/actualización de Unicorn no funciona

El comando de reinicio nunca funcionó para mí. Estoy usando la actualización para reiniciar el unicornio después de cada implementación. Pero cuando hay cambios importantes como nuevas gemas que se agregan, la actualización no funcionará. Recientemente, reemplacé hoptoad gem con airbrake y se equivoca diciendo 'Airbrake constante no inicializada (NameError)'. Pero cuando me detuve y comencé a unicornio nuevamente, funcionó bien. ¿El problema radica en el guión de inicio o en su problema diferente?

Gracias.

Respuesta

11

De acuerdo con su guión de inicio, "reinicio /bin/init.d/unicorn" envía una señal HUP al proceso maestro unicornio

------ recortada

restart|reload) 
    sig HUP && echo reloaded OK && exit 0 
    echo >&2 "Couldn't reload, starting '$CMD' instead" 
    su - $USER -c "$CMD" 

---- -cropped

Esto es lo que hace al proceso de HUP unicornio:

vuelve a cargar el archivo de configuración y con gracia reiniciar todos los trabajadores. Si la directiva "preload_app" es falsa (la predeterminada), los trabajadores también recogerán los cambios en el código de la aplicación cuando se reinicien. Si "preload_app" es verdadero, entonces los cambios en el código de la aplicación no tendrán efecto.

¡Lo que está buscando es la señal USR2 que su parámetro de actualización al unicornio ya está haciendo!

La señal USR2 vuelve a ejecutar el binario en ejecución. Se debe enviar un QUIT por separado al proceso original una vez que se haya verificado que el niño está en funcionamiento.

+0

Si bien esto es correcto, no podemos decir cuál es su problema sin ver las configuraciones de unicornio. Básicamente, si establece 'preload_app' en cierto lugar, necesitarás usar el comando de" actualización "Y necesitarás tener un código adicional en tu configuración de unicornio para que funcione. Google "Unicorn zero downtime deploy" debería mostrar ejemplos. Si ** no configura ** 'preload_app', su' reinicio' sería la opción correcta, pero reiniciará completamente el servidor, causando que esté desconectado por un momento. – averell

10

que tenía un problema muy similar y finalmente found the solution

me había mirado a través de los registros antes pero, obviamente, no pudo ver el error (Bundler::GemfileNotFound). Resulta que hay referencias antiguas a versiones anteriores y una vez que el archivo gem cambia, el nuevo maestro falla silenciosamente. Tail -f tu registro de unicornio para ver qué pasa. Mis problemas fueron fijados según el enlace con la siguiente en mi unicorn.rb

before_exec do |server| 
    ENV['BUNDLE_GEMFILE'] = "#{root}/Gemfile" 
end 
+3

[Este] (https://github.com/sosedoff/capistrano-unicorn/commit/c1e7a3f2794dd070367d0808ad102a6d20d39cf2) puede ser una solución un poco mejor. – Anjan

+0

@anjan Sí, buen descubrimiento. No estoy usando la joya Capistrano-unicornio en este momento, pero sería una buena solución para aquellos que sí lo son. – toxaq

2

que tenía el mismo problema, pero yo estaba usando rbenv que fue instalado en base por usuario. He utilizado este init script

me di cuenta de que desde mi rbenv instalado en función de cada usuario que necesito cambiar algo esto:

CMD="cd $APP_ROOT; bundle exec unicorn -D -c $APP_ROOT/config/unicorn.rb -E production" 

con esto:

CMD="cd $APP_ROOT; ~/.rbenv/bin/rbenv exec bundle exec unicorn -D -c $APP_ROOT/config/unicorn.rb -E production" 

espero que le ayudará !

P.S. o alguien más, ya que es una vieja pregunta =)

0

He solucionado este problema al cambiar el inicio de mi unicornio.d script desde

CMD="cd $APP_ROOT; bundle exec unicorn -D -c $APP_ROOT/config/unicorn.rb -E staging" 

a esto:

CMD="cd $APP_ROOT; BUNDLE_GEMFILE=$APP_ROOT/Gemfile bundle exec unicorn -D -c $APP_ROOT/config/unicorn.rb -E staging" 

que parece apuntar a la nueva Gemfile paquete en cada nueva versión. Inspirándose en this merge request