Upgrade von /admin/upgrade dauert *sehr* lange

Fehler
1

Beim Upgrade eines einzelnen Plugins von admin/upgrade dauert es sehr lange.

Normalerweise ist ein vollständiger Neuaufbau in etwa 7 Minuten erledigt.

Es wird seit 2023-03-02T20:07:00Z aktualisiert, der aktuelle Status ist:

image
image1209×628 171 KB

HTOP-Ausgabe:

image
image927×202 48.7 KB

EDIT: 2023-03-02T20:44:00Z - immer noch auf derselben Log-Zeile. CPU unverändert. CLI-Neuerstellung zu diesem Zeitpunkt initiiert.

EDIT2: Um die genaue Zeit anzugeben, die eine Neuerstellung auf meinem Computer dauert, Zeitstempel für den Abschluss der Neuerstellung: 2023-03-02T20:51:00Z

4 „Gefällt mir“
2

Ja, ich habe seit gestern dasselbe Problem.\n\nEs ist jetzt mehr oder weniger unmöglich, über den Upgrade-Bildschirm in angemessener Zeit ein Upgrade durchzuführen, sodass Sie gezwungen sind, über die Befehlszeile ein Upgrade durchzuführen.

3

CLI-Neuerstellung wurde abgeschlossen.

Admin-Upgrade steckt immer noch fest und es sieht nicht so aus, als wäre das Plugin aktualisiert worden.

image
image386×168 6.51 KB

Ich habe auf RESET UPGRADE geklickt und einen weiteren CLI-Neuerstellung initiiert.

1 „Gefällt mir“
4

Ich auch, ich habe genau dasselbe. Sehr ärgerlich beim Aktualisieren von Plugins, es dauert wirklich sehr, sehr lange - extrem unpraktisch.

2 „Gefällt mir“
5

Gibt es eine Umgehungslösung dafür? Jedes Mal, wenn ich ein Upgrade durchführe, um mit den Änderungen in Discourse Chatbot :robot: (Supports ChatGPT) - plugin - Discourse Meta Schritt zu halten, dauert es so lange.

6

Dies ist immer noch ein Problem.

Betrifft es jedoch nur die Server mit geringerer Spezifikation?

1 „Gefällt mir“
9

Nur um eine zusätzliche Stimme beizusteuern, anstatt Antworten… :slight_smile:

Ich habe eine winzige 1GB DO-Testseite mit vielen Plugins, daher ist sie normalerweise nicht die schnellste. Ich glaube jedoch, dass sie in letzter Zeit auch viel länger braucht, und meine ist neulich wie bei @MarcP in einer seltsamen Situation stecken geblieben und ich musste sie zurücksetzen.

Ich habe sie noch nie gestoppt, aber heute habe ich sie auf ‘Alle aktualisieren’ gestellt und mir notiert, wann ich auf den Knopf gedrückt habe. Bisher hatten wir einen Start um 9:30 Uhr, und es läuft immer noch um 10:15 Uhr. Sie bündelt gerade einige Assets. Ich kann mit einiger Zuversicht sagen, dass es normalerweise nicht über 45 Minuten dauert, um ihre Arbeit zu erledigen.

Es sieht jedoch so aus, als hätte sie einige Berechtigungsprobleme beim Löschen von temporären Dateien gehabt? Nicht sicher, ob das relevant ist.

4 „Gefällt mir“
11

@david und ich haben die Ursache gefunden. (ähnlich wie @Falco in der Vergangenheit)

Wir verwenden spezielle Ruby-Flags, um den Speicher während Upgrades zu begrenzen, und dies funktioniert unter Ruby 3.2 nicht mehr.

Wir werden bald einen PR haben, um das Problem zu beheben.

7 „Gefällt mir“
12
7 „Gefällt mir“
13

Hinweis… damit die Korrektur wirksam wird, gibt es eine Art Henne-Ei-Problem. Alter Code wird immer noch geladen, wenn Sie das Upgrade ausführen.

Möglicherweise benötigen Sie beim ersten Mal ein ./launcher rebuild und danach funktioniert der Web-Upgrader.

Keine einfache Lösung dafür. @cvx, das ist ein kniffliges Problem… technisch gesehen sollten wir es so einrichten, dass DockerManager::Upgrader.new(user_id, repo, repo_version).upgrade auslagert und beim Upgrade neuen Upgrader-Code ausführt … aber das ist eine Büchse der Pandora.

Schnelle Problemumgehung

  1. Starten Sie die Docker-Manager-Aktualisierung.
  2. Brechen Sie ab, wenn sie stecken bleibt.
  3. Führen Sie ./launcher restart app in der Shell aus.
  4. Die Aktualisierung über das Web funktioniert.

Einfache Problemumgehung

  1. Führen Sie ./launcher rebuild app aus.

Danach ist alles in Ordnung.

EDIT

Schließe dies vorsorglich, da dies der letzte Beitrag zu diesem Thema sein soll. Das erleichtert es den Leuten, die Problemumgehungen zu finden. Markieren Sie zur Wiedereröffnung, falls nach einem Rebuild weiterhin ein Problem besteht.

8 „Gefällt mir“