Capistrano no reinicia correctamente los clústeres Mongrel

Question

Tengo un clúster de tres mongrels ejecutándose bajo nginx, y despliego la aplicación usando Capistrano 2.4.3. Cuando "límite de implementación" cuando hay un sistema en ejecución, el comportamiento es:

1. La aplicación se implementó. El código se actualizó con éxito.

2. En la salida de la tapa de despliegue, no es lo siguiente:

   • ejecutar "sudo -p 'sudo contraseña:' mongrel_rails cúmulo :: reinician -C /var/www/rieles/miaplicacion/corriente/config/mongrel_cluster.yml"
   • servidores: [ "MyIP"]
   • [MyIP] comando de ejecución de
   • ** [:: cabo MyIP] detener el puerto 9096
   • ** [:: cabo MyIP] parar puerto 9097
   • ** [:: cabo MyIP] detener el puerto 9098
   • ** [:: cabo MyIP] comenzado ya el puerto 9096
   • ** [:: cabo MyIP] comenzado ya el puerto 9097
   • ** [ out :: myip] ya inició el puerto 9098
3. Compruebo inmediatamente en el servidor y encuentro 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 comienzo mongrel en el servidor a mano, la aplicación se inicia correctamente.

Parece que 'mongrel_rails cúmulo :: reinicio' no es propiamente la espera de un punto antes de intentar un reinicio del clúster. ¿Cómo diagnostico y arreglo este problema?

EDIT: Aquí está la respuesta:

mongrel_cluster, en la tarea de "reinicio", sólo hace esto:

def run 
    stop 
    start 
end 

No hace ninguna espera o la comprobación para ver que el proceso de salir antes invocando "inicio". Esto es a known bug with an outstanding patch submitted. Apliqué el parche a Mongrel Cluster y el problema desapareció.

Answer 1

Se puede decir de manera explícita las recetas mongrel_cluster para eliminar los archivos de esta enfermedad antes de empezar añadiendo lo siguiente en sus recetas Capistrano:

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

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

Volví 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. Echar un vistazo al siguiente mensaje en el grupo de usuarios sin raza:

mongrel users discussion of restart

La siguiente es mi implementar: tarea de reinicio. Admito que es un poco hack.

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

Odio ser tan básico, pero parece que los archivos pid siguen dando vueltas cuando está intentando comenzar. Asegúrate de que el mestizo esté parado a mano. Limpie los archivos pid a mano. Luego haz un despliegue de tapa.

Answer 3

En primer lugar, reduzca el alcance de sus pruebas solo llamando al cap deploy:restart. Es posible que desee pasar la opción --debug para solicitar antes de la ejecución remota o la opción --dry-run solo para ver lo que sucede mientras ajusta su configuración.

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

• la variable :runner se establece explícitamente a nil - ¿Había una razón específica para esto?
• Capistrano 2.4 introdujo un nuevo comportamiento para la variable :admin_runner. Sin ver toda la receta, ¿está posiblemente relacionado con su problema?

  : corredor vs.: admin_runner (de capistrano 2.4 release) Algunos tapadoras han observado que tener desplegar: configurar y desplegar: la limpieza de ejecución como el corredor del usuario en mal estado sus permisos cuidadosamente elaborados. Estuve de acuerdo en que esto era un problema. Con este lanzamiento, implemente: iniciar, implementar: detener e implementar: reiniciar todo continúe usando el usuario: runner al hacer sudo, pero implementar: configurar e implementar: la limpieza usará el usuario: admin_runner. La variable: admin_runner está desactivada, por defecto, lo que significa que las tareas se sudo como root, pero si quieres que se ejecuten como: runner, simplemente haz "set: admin_runner, runner".

Mi recomendación para qué hacer a continuación. Detenga manualmente a los chuchos y limpie los PID. Comience los mestizos manualmente. A continuación, continúe ejecutando cap deploy:restart al depurar el problema. Repita según sea necesario.

Answer 4

De cualquier manera, mis mestizos comienzan antes de que el comando de parada anterior haya terminado de cerrarlos.

sleep 2.5 no es una buena solución, si se tardan más de 2,5 segundos en detener a todos los mestizos en ejecución.

Parece que hay una necesidad de:

stop && start 

vs

stop; start 

(esto es cómo funciona el golpe, & & espera a que el primer comando para terminar w/o de error, mientras ";" simplemente ejecuta el siguiente comando).

Me pregunto si hay una:

wait cluster_stop 
then cluster_start 

Answer 5

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