Capistrano no reinicia correctamente los grupos mestizos

Question

Tengo un grupo de tres mestizos corriendo bajo nginx, e implemento la aplicación usando Capistrano 2.4.3. Cuando yo " cap despliegue " cuando hay un sistema en ejecución, el comportamiento es:

1. La aplicación está desplegada. El código se actualiza con éxito.

2. En la salida de despliegue de la tapa, hay esto:

   • ejecutando " sudo -p 'contraseña de sudo:' mongrel_rails cluster :: restart -C /var/www/rails/myapp/current/config/mongrel_cluster.yml"
   • servidores: [" myip "]
   • [myip] ejecutando el comando
   • ** [out :: myip] deteniendo el puerto 9096
   • ** [out :: myip] deteniendo el puerto 9097
   • ** [out :: myip] deteniendo el puerto 9098
   • ** [out :: myip] ya inició el puerto 9096
   • ** [out :: myip] ya comenzó el puerto 9097
   • ** [out :: myip] ya comenzó el puerto 9098
3. Reviso inmediatamente en el servidor y descubro que Mongrel todavía se está ejecutando, y los archivos PID todavía están presentes en las tres instancias anteriores.
4. Poco tiempo después (menos de un minuto), encuentro que Mongrel ya no se está ejecutando, los archivos PID se han ido y no se ha podido reiniciar.
5. Si inicio mongrel en el servidor con la mano, la aplicación se inicia correctamente.

Parece que 'mongrel_rails cluster :: restart' no está esperando correctamente una parada completa Antes de intentar reiniciar el cluster. ¿Cómo puedo diagnosticar y solucionar este problema?

EDITAR: Aquí está la respuesta:

mongrel_cluster, en el " reinicio " tarea, simplemente hace esto:

 def run
   stop
   start
 end

No hace ninguna espera o comprobación para ver que el proceso haya finalizado antes de invocar " iniciar " ;. Esto es un error conocido con un parche pendiente enviado . Apliqué el parche a Mongrel Cluster y el problema desapareció.

Answer 1

Puede indicar explícitamente a las recetas de mongrel_cluster que eliminen los archivos pid antes de comenzar agregando lo siguiente en sus recetas de capistrano:

# helps keep mongrel pid files clean
set :mongrel_clean, true

Esto hace que pase la opción --clean a mongrel_cluster_ctl.

Regresé y miré una de mis recetas de implementación y noté que también había cambiado la forma en que funcionaba mi tarea de reinicio. Eche un vistazo al siguiente mensaje en el grupo de usuarios mestizos:

discusión de reinicio de usuarios mongrel

El siguiente es mi tarea de despliegue: reinicio. Admito que es un poco pirateado.

namespace :deploy do
  desc "Restart the Mongrel processes on the app server."
  task :restart, :roles => :app do
    mongrel.cluster.stop
    sleep 2.5
    mongrel.cluster.start
  end
end

Answer 2

Primero, reduzca el alcance de sus pruebas llamando solo a cap deploy: restart . Es posible que desee pasar la opción --debug para preguntar antes de la ejecución remota o la opción --dry-run solo para ver qué sucede a medida que modifica la configuración.

A primera vista, esto suena como un problema de permisos en los archivos pid o procesos mestizos, pero es difícil saberlo con seguridad. Un par de cosas que me llaman la atención son:

• la variable : runner está explícitamente establecida en nil : ¿hubo alguna razón específica para esto?
• Capistrano 2.4 introdujo un nuevo comportamiento para la variable : admin_runner . Sin ver la receta completa, ¿es posible que esto esté relacionado con su problema?

    

  : runner vs.: admin_runner (de versión 2.4 de capistrano )   Algunos bloqueadores han notado que al haber implementado: instalación y despliegue: la limpieza se ejecuta cuando el usuario del corredor arruina sus permisos cuidadosamente diseñados. Estuve de acuerdo en que esto era un problema. Con esta versión, implemente: inicie, despliegue: detenga, e implemente: reinicie todos continúe usando el: runner user cuando realice sudo, pero despliegue: setup and deploy: cleanup usará el: admin_runner user. La variable: admin_runner no está establecida, por defecto, lo que significa que las tareas sudo como root, pero si desea que se ejecute como: runner, simplemente haga & # 8220; set: admin_runner, runner & # 8221 ;.

Mi recomendación sobre qué hacer a continuación. Detenga manualmente los mestizos y limpie los PID. Arranca los mestizos manualmente. A continuación, continúe ejecutando cap deploy: restart mientras se depura el problema. Repita según sea necesario.

Answer 3

De cualquier manera, mis mestizos están comenzando antes de que el comando de detención anterior haya terminado de cerrarlos.

dormir 2.5 no es una buena solución, si demora más de 2.5 segundos detener a todos los perros callejeros.

Parece que hay una necesidad de:

stop && start

vs.

stop; start

(así es como funciona bash, & amp; & amp; y espera a que el primer comando finalice sin error, mientras que " ;; " simplemente ejecuta el siguiente comando).

Me pregunto si hay un:

wait cluster_stop
then cluster_start

Answer 4

No me gusta ser tan básico, pero parece que los archivos pid todavía están pendientes cuando está intentando iniciarse. Asegúrese de que el mestizo se detiene a mano. Limpie los archivos pid a mano. Luego haz un despliegue de límite.

Answer 5

Buena discusión: http://www.ruby-forum.com/topic/ 139734 # 745030