Ich habe zwei Jobs, die gleichzeitig in die Warteschlange gestellt werden und ein Arbeiter führt sie nacheinander aus. Beide Jobs kopieren einige Dateien aus dem Verzeichnis builds/ im Stammverzeichnis meines Rails-Projekts und legen sie in einen temporären Ordner.
Der erste Job ist immer erfolgreich, niemals ein Problem - es spielt keine Rolle, welcher Job zuerst ausgeführt wird. Der erste wird funktionieren.
Der zweite Fehler wird beim Kopieren der Dateien angezeigt:
Keine solche Datei oder kein Verzeichnis - / Benutzer / Apps / Sites / Meine-Site / Releases / 20130829065128 / Builds / foo
Dieser Ordner ist zwei Wochen alt und sollte nicht auf dem Server sein. Es ist leer und enthält nur ein öffentliches / uploads-Verzeichnis und sonst nichts. Ich habe alle meine Mitarbeiter getötet und mehrere Male neu gestartet und die Rails-App mehrere Male erneut implementiert. Wenn ich das Veröffentlichungsverzeichnis lösche, wird es erneut gemacht.
Ich weiß nicht, was ich zu diesem Zeitpunkt tun soll. Warum sollte dieser Worker immer in diesem alten Versionsverzeichnis suchen? Warum sollte nur der zweite Arbeiter das tun? Ich bekomme den Pfad mit:
Rails.root.join('builds') - Rails.root ist anscheinend eine 2 Wochen alte Capistrano-Veröffentlichung? Ich sollte auch erwähnen, dass dies nur in der Produktionsumgebung passiert. Was kann ich tun
?
Rescue wird bei Bereitstellungen nicht neu gestartet (gestoppt und gestartet), wodurch alte Versionen des Codes ausgeführt werden. Jeder Worker bedient weiterhin die Warteschlange, was zu merkwürdigen Fehlern oder Verhaltensweisen führt.
Basierend auf dem Pfadnamen sieht es so aus, als ob Sie Capistrano für die Bereitstellung verwenden.
Benutzt du den Edelstein capistrano-resque ? Wenn nicht, sollten Sie einen Blick darauf werfen.
Ich hatte genau das gleiche Problem und hier ist, wie ich es gelöst habe:
In meinem Fall war das Problem, wie capistrano die PID-Dateien behandelt, die angeben, welche Worker gerade existieren. Diese Dateien werden normalerweise in tmp/pids/ gespeichert. Sie müssen capistrano NOT mitteilen, sie nicht in jedem Release-Ordner zu speichern, sondern in shared/tmp/pids/ . Andernfalls weiß resque nicht, welche Mitarbeiter gerade ausgeführt werden, nachdem Sie eine neue Bereitstellung vorgenommen haben. Es untersucht den pids-Ordner der neuen Version und findet keine Datei. Daher wird angenommen, dass keine Arbeiter existieren, die abgeschaltet werden müssen. Resque erstellt nur neue Mitarbeiter. Und alle anderen Arbeiter existieren noch, aber Sie können sie nicht im Resque-Dashboard sehen. Sie können sie nur sehen, wenn Sie die Prozesse auf dem Server überprüfen.
Folgendes müssen Sie tun:
Fügen Sie die folgenden Zeilen in Ihrem deploy.rb hinzu (übrigens verwende ich Capistrano 3.5)
%Vor% Führen Sie auf dem Server htop im Terminal aus, um htop zu starten, und drücken Sie dann T, um alle Prozesse anzuzeigen, die gerade ausgeführt werden. Es ist leicht, all diese Resque-Worker-Prozesse zu erkennen. Sie können auch den Namen des Freigabeordners sehen.
Sie müssen alle Arbeitsprozesse von Hand erledigen. Verlassen Sie htop und geben Sie den folgenden Befehl ein, um alle resque-Prozesse zu beenden (ich möchte es ganz sauber haben):
%Vor%Jetzt können Sie eine neue Bereitstellung vornehmen. Sie müssen auch den Resque-Scheduler erneut starten.
Ich hoffe, das hilft.
Tags und Links ruby-on-rails capistrano resque