Capistrano ne redémarre pas correctement les clusters Mongrel

Question

J'ai un cluster de trois modèles gérés par nginx et je déploie l'application à l'aide de Capistrano 2.4.3. Quand je "cap deploy" " quand il y a un système en fonctionnement, le comportement est le suivant:

1. L'application est déployée. Le code est mis à jour avec succès.

2. Dans la sortie du déploiement de cap, il y a ceci:

   • exécuter "sudo -p 'mot de passe sudo:" mongrel_rails cluster :: restart -C /var/www/rails/myapp/current/config/mongrel_cluster.yml"
   • serveurs: [" myip "]
   • [myip] commande d'exécution
   • ** [out :: myip] arrêt du port 9096
   • ** [out :: myip] arrêtant le port 9097
   • ** [out :: myip] arrêt du port 9098
   • ** [out :: myip] a déjà commencé le port 9096
   • ** [out :: myip] a déjà commencé le port 9097
   • ** [out :: myip] déjà démarré le port 9098
3. Je vérifie immédiatement sur le serveur et trouve que Mongrel est toujours en cours d'exécution et que les fichiers PID sont toujours présents pour les trois instances précédentes.
4. Peu de temps après (moins d'une minute), je constate que Mongrel n'est plus en cours d'exécution, que les fichiers PID ont disparu et que son redémarrage a échoué.
5. Si je lance bâtard à la main sur le serveur, l'application démarre parfaitement.

Il semble que 'cluster_mongrel_rails :: restart' n'attend pas correctement un arrêt complet avant de tenter un redémarrage du cluster. Comment diagnostiquer et résoudre ce problème?

EDIT: voici la réponse:

mongrel_cluster, dans le "redémarrage" tâche, fait simplement ceci:

 def run
   stop
   start
 end

Il n'est pas nécessaire d'attendre ou de vérifier que le processus s'est terminé avant d'appeler "start". C’est un bogue connu lié à un correctif exceptionnel envoyé . . J'ai appliqué le correctif à Mongrel Cluster et le problème a disparu.

Answer 1

Vous pouvez explicitement demander aux recettes de mongrel_cluster de supprimer les fichiers pid avant de commencer en ajoutant ce qui suit dans vos recettes capistrano:

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

Cela lui fait passer l'option --clean à mongrel_cluster_ctl.

Je suis revenu en arrière et j'ai consulté l'une de mes recettes de déploiement. J'ai remarqué que j'avais également changé la façon dont ma tâche de redémarrage fonctionnait. Regardez le message suivant dans le groupe d’utilisateurs métisses:

discussion entre redémarreurs

Voici ma tâche de déploiement: redémarrer. J'avoue que c'est un peu un bidouillage.

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

Tout d'abord, limitez la portée de vos tests en appelant uniquement cap deploy: restart . Vous pouvez passer l'option - debug à l'invite avant l'exécution à distance ou l'option - dry-run afin de voir ce qui se passe lorsque vous peaufinez vos paramètres.

À première vue, cela ressemble à un problème d’autorisations sur les fichiers pid ou les processus bâtard, mais il est difficile de le savoir avec certitude. Quelques choses qui attirent mon attention sont:

• la variable : runner est explicitement définie sur nil - Y avait-il une raison spécifique à cela?
• Capistrano 2.4 a introduit un nouveau comportement pour la variable : admin_runner . Sans voir la recette complète, est-ce que cela est probablement lié à votre problème?

    

  : runner vs: admin_runner (from version capistrano 2.4 )   Certains cappers ont remarqué qu'avoir deploy: setup et deploy: cleanup s'exécutait sous le nom d'utilisateur: runner, ce qui leur donnait des permissions soigneusement conçues. J'ai convenu que c'était un problème. Avec cette version, deploy: start, deploy: stop, et deploy: restart tous continuent à utiliser l'utilisateur: runner lors de l'exécution, mais deploy: setup et deploy: cleanup utilisera l'utilisateur: admin_runner. La variable: admin_runner n'est pas définie, par défaut, ce qui signifie que ces tâches seront sudo en tant que root, mais si vous voulez qu'elles s'exécutent en tant que: runner, il suffit de faire "set: admin_runner, runner".

Ma recommandation pour la suite des choses. Arrêtez manuellement les bâtards et nettoyez les PID. Démarrez les bâtons manuellement. Ensuite, continuez à exécuter cap deploy: restart tout en déboguant le problème. Répétez si nécessaire.

Answer 3

Quoi qu’il en soit, mes bâtons commencent avant que la commande d’arrêt précédente ait fini de tout arrêter.

sleep 2.5 n'est pas une bonne solution s'il faut plus de 2,5 secondes pour arrêter tous les routines en cours d'exécution.

Il semble y avoir un besoin pour:

stop && start

vs.

stop; start

(c’est ainsi que bash fonctionne, & attend de la fin de la première commande sans erreur, alors que " ;; exécute simplement la commande suivante).

Je me demande s'il existe un:

wait cluster_stop
then cluster_start

Answer 4

Je déteste être aussi basique, mais il semble que les fichiers pid traînent toujours au moment où il essaie de démarrer. Assurez-vous que le métis est arrêté à la main. Nettoyez les fichiers pid à la main. Ensuite, effectuez un déploiement de casquette.

Answer 5

Bonne discussion: http://www.ruby-forum.com/topic/ 139734 # 745030