Capistrano Neustart nicht Mongrel Cluster richtig

StackOverflow https://stackoverflow.com/questions/155234

Frage

Ich habe eine Gruppe von drei Bastarde unter nginx ausgeführt wird, und ich implementieren die App mit Capistrano 2.4.3. Als ich „cap deploy“, wenn ein laufendes System ist, das Verhalten ist:

  1. Die App ist im Einsatz. Der Code wird erfolgreich aktualisiert.

  2. In der Kappe deploy Ausgabe gibt es diese:

    • Ausführen „sudo -p 'sudo Passwort:' mongrel_rails Cluster :: Neustart -C /var/www/rails/myapp/current/config/mongrel_cluster.yml "
    • Server: [ "myip"]
    • [myip] Ausführen-Befehl
    • ** [out :: myip] stoppen Port 9096
    • ** [out :: myip] stoppen Port 9097
    • ** [out :: myip] stoppen Port 9098
    • ** [out :: myip] bereits begonnen Port 9096
    • ** [out :: myip] bereits begonnen Port 9097
    • ** [out :: myip] bereits begonnen Port 9098
  3. Ich prüfe sofort auf dem Server und finden, dass Mongrel noch läuft, und die PID-Dateien sind noch vorhanden für die letzten drei Instanzen.
  4. Eine kurze Zeit später (weniger als eine Minute), finde ich, dass Mongrel nicht mehr ausgeführt wird, werden die PID-Dateien verschwunden, und es kann nicht neu gestartet werden.
  5. Wenn ich nicht reinrassig auf den Server von Hand starten, startet die App bis gut.

Es scheint wie ‚mongrel_rails Cluster :: restart‘ nicht richtig für einen Punkt wartet bevor ein Neustart des Clusters versucht. Wie kann ich die Diagnose und das Problem beheben?

EDIT: Hier ist die Antwort:

mongrel_cluster, in der "Neustart" Aufgabe, einfach tut dies: 

 def run
   stop
   start
 end

Es wird keine Warte tun oder zu überprüfen, dass der Prozess vor dem Aufruf beendet „Start“. Dies ist ein bekannter Fehler mit einem hervorragenden Patch eingereicht . Ich bewarb mich um den Patch zu Mongrel Cluster und das Problem verschwunden.

War es hilfreich?

Lösung

Sie können die mongrel_cluster Rezepte explizit sagen die pid-Dateien vor einem Start zu entfernen, indem Sie die folgenden in Ihrer Capistrano Rezepte hinzufügen: 

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

Dies bewirkt, dass es die --clean Option passieren mongrel_cluster_ctl.

Ich ging zurück und sah eine meiner Einsatz Rezepte und bemerkte, dass ich auch die Art und Weise gearbeitet meine restart task verändert hatte. Werfen Sie einen Blick auf die folgende Meldung in der Mischlingsbenutzergruppe:

Mischlings Benutzer Diskussion des Neustarts

Hier finden Sie meine deploy: restart task. Ich gebe zu, es ist ein bisschen wie ein 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

Andere Tipps

Zuerst verengen den Umfang dessen, was Ihre Tests von nur cap deploy:restart aufrufen. Vielleicht möchten Sie die --debug Option passieren, bevor Remote-Ausführung oder die --dry-run Option aufzufordern, nur um zu sehen, was los ist, wie Sie Ihre Einstellungen optimieren.

Auf den ersten Blick klingt dies wie ein Problem mit den Berechtigungen auf die pid-Dateien oder Mischlings Prozesse, aber es ist schwierig, sicher zu wissen. Ein paar Dinge, die mir ins Auge fallen, sind:

  • die :runner Variable ist explizit auf nil - Gab es einen bestimmten Grund für diese
  • Capistrano 2.4 ein neues Verhalten für die :admin_runner Variable eingeführt. Ohne das gesamte Rezept zu sehen, ist dies möglicherweise zu Ihrem Problem zu tun hat?
      

    : Läufer gegen: admin_runner (von Capistrano 2.4 Release )   Einige cappers haben festgestellt, dass mit implementieren: Einrichten und Bereitstellen: Bereinigungslauf als: läufer Benutzer ihre Berechtigungen sorgfältig gestaltete vermasselt. Ich stimmte zu, dass dies ein Problem war. Mit dieser Version einsetzen: Start, bereitstellen: stoppen und bereitstellen: starten Sie alle weiterhin die verwenden: Läufer Benutzer, wenn sudoing, aber bereitstellen: Setup und bereitstellen: die Bereinigung verwenden: admin_runner Benutzer. Die: admin_runner Variable ist nicht gesetzt, standardmäßig die Aufgaben Bedeutung wird sudo als root, aber wenn Sie wollen, wie laufen: Läufer, nur tun „gesetzt: admin_runner, runner“.

Meine Empfehlung für das, was als nächstes zu tun. Beenden Sie manuell die Bastarde und reinigen Sie die PIDs auf. Starten Sie die manuell Bastarde. Als nächstes weiterhin cap deploy:restart laufen, während das Problem debuggen. Bei Bedarf wiederholen.

So oder so, meine Bastarde beginnen, bevor der vorherige Stopp-Befehl beendet herunter Sie sich alle ab.

schlafen 2.5 ist keine gute Lösung, wenn es länger dauert als 2,5 Sekunden alle laufenden Bastarde zu stoppen.

Es scheint ein Bedürfnis zu sein: 

stop && start

vs. 

stop; start

(dies ist, wie bash funktioniert, && wartet, bis der erste Befehl w / o Fehler zu beenden, während „“ einfach den nächsten Befehl ausgeführt wird).

Ich frage mich, wenn es ein: 

wait cluster_stop
then cluster_start

Ich hasse so grundlegend zu sein, aber es klingt wie die pid-Dateien um noch hängen, wenn es versucht zu starten. Stellen Sie sicher, dass Mischlings von Hand gestoppt wird. Reinigen Sie die pid-Dateien von Hand. Dann machen Sie eine Kappe deploy.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top