Fehler beim Neubau: registry.yarnpkg.com ESOCKETTIMEDOUT

Installation
1

Ich betreibe eine selbst gehostete Instanz von Discourse unter https://forum.embeetle.com.

Gestern ist das Ein-Klick-Browser-Upgrade fehlgeschlagen, also habe ich mich auf dem Server angemeldet und versucht, ./launcher rebuild app auszuführen.

Dies schlug ebenfalls fehl, mit der folgenden Fehlermeldung:

I, [2024-08-01T20:46:09.837292 #1]  INFO -- : 
I, [2024-08-01T20:46:09.837631 #1]  INFO -- : cd /var/www/discourse & su discourse -c 'yarn install --frozen-lockfile & yarn cache clean'
warning Resolution field "unset-value@2.0.1" is incompatible with requested version "unset-value@^1.0.0"
error Error: https://registry.yarnpkg.com/date-fns/-/date-fns-3.6.0.tgz: ESOCKETTIMEDOUT
    at ClientRequest.<anonymous> (/usr/share/yarn/lib/cli.js:142037:19)
    at Object.onceWrapper (node:events:631:28)
    at ClientRequest.emit (node:events:517:28)
    at TLSSocket.emitRequestTimeout (node:_http_client:847:9)
    at Object.onceWrapper (node:events:631:28)
    at TLSSocket.emit (node:events:529:35)
    at Socket._onTimeout (node:net:598:8)
    at listOnTimeout (node:internal/timers:569:17)
    at process.processTimers (node:internal/timers:512:7)

Danach scheint der Befehl zu hängen (nichts passiert für mindestens 10 Minuten), also habe ich ihn beendet und es erneut versucht. Gleiches Ergebnis.

Es gibt kein Netzwerkproblem: Innerhalb des Docker-Containers (./launcher enter app) gibt wget https://registry.yarnpkg.com/date-fns/-/date-fns-3.6.0.tgz erfolgreich in weniger als 0,1 Sekunden zurück.

Ich habe mir dieses ähnliche Problem angesehen: Error during the update ESOCKETTIMEDOUT registry.yarnpkg.com - #4 by jericson Der dortige Vorschlag ist, das Timeout zu erhöhen, indem /var/discourse/templates/web.template.yml bearbeitet wird.

Leider existiert dieser Pfad in meiner Installation nicht (innerhalb des Docker-Containers gibt es kein /var/discourse; es gibt einen Ordner var/www/discourse, der das Standardarbeitsverzeichnis beim Betreten der App ist, aber dieser hat keinen Unterordner templates; ich habe nach web.template.yml gesucht, konnte es aber nirgends finden.

Ich bin auch nicht sehr zuversichtlich, dass die Erhöhung des Timeouts das Problem beheben würde, angesichts des sehr schnellen Downloads von https://registry.yarnpkg.com/date-fns/-/date-fns-3.6.0.tgz.

Ich habe schließlich ein Backup von vor ein paar Tagen wiederhergestellt, mit einer älteren Version von Discourse, und die aktuellste Version von discourse/shared hineinkopiert. Das funktioniert, also ist das Forum wieder online.

Stimmt etwas mit der neuesten Version im Main-Branch nicht? Ich habe tatsächlich versucht, ./launcher rebuild app erneut auszuführen, und es schlägt wieder auf die gleiche Weise fehl, also musste ich das Forum erneut aus dem Backup wiederherstellen.

1 „Gefällt mir“
2

Ich glaube, das Problem ist nicht das Abrufen der einzelnen Pakete, sondern die Gesamtzeit, die für die Installation aller Pakete benötigt wird. Wenn Sie nicht genügend Speicher haben, können Sie das Problem haben, auch wenn Ihre Netzwerkgeschwindigkeit in Ordnung ist. Die E2.Micro-Instanz, mit der ich das Problem hatte, hat nur 1 GB Speicher.

Was es wert ist, ich habe gerade Discourse auf einem 4GB Droplet aktualisiert und keine besonderen Probleme festgestellt.

3

Ich verwende einen VPS mit 32 GB RAM, derzeit sind 24 GB frei; Speicher sollte also kein Problem sein.

1 „Gefällt mir“
4

Du kannst versuchen

 ./launcher start app

um den alten Container wieder zum Laufen zu bringen.
Das löst das Problem zwar nicht, sollte deine Seite aber wieder zum Laufen bringen. Du solltest kein Backup wiederherstellen müssen.

/var/discourse befindet sich außerhalb des Containers, nicht darin. Diese Vorlage baut die Dinge im Container, daher ist das einen Versuch wert.

Außerdem würde ich bei so viel RAM wie du hast, auf ein 2-Container-Setup umsteigen, damit du ohne Herunterfahren deiner Seite starten kannst.

1 „Gefällt mir“
5

Leider bringt der einfache Aufruf von

./launcher start app

das Forum nicht wieder zum Laufen.

Ich habe weitere Experimente durchgeführt. Insbesondere habe ich versucht, den fehlschlagenden Yarn-Befehl manuell im Docker-Image auszuführen:

./launcher enter app
cd /var/www/discourse
su discourse
yarn install --frozen-lockfile
... schlägt mit demselben Timeout fehl ...
yarn config set network-timeout 600000 -g
yarn install --frozen-lockfile
... erfolgreich ...

Dies bestätigt, dass die Erhöhung des Timeouts das Problem behebt.

Die verbleibende Frage ist also, wie man den Timeout auch während ./launcher rebuild app erhöhen kann.

Die Datei web.template.yml befindet sich tatsächlich in discourse/containers außerhalb des Docker-Images. Ich habe sie zunächst nicht gefunden, da sich meine Discourse-Installation an einem nicht standardmäßigen Ort befindet und nicht in /var/discourse.

Die im oben genannten Beitrag erwähnte Korrektur bezieht sich auf Zeile 159, aber das scheint nicht mehr korrekt zu sein, wahrscheinlich aufgrund von Updates. Es gibt jedoch diese Zeilen um Zeile 188:

  - exec:
      cd: $home
      hook: yarn
      cmd:
        - |
          if [ "$version" != "tests-passed" ]; then
            rm -rf app/assets/javascripts/node_modules
          fi
        - su discourse -c 'yarn install --frozen-lockfile &amp;&amp; yarn cache clean'

Der Beitrag schlägt vor, einen neuen Abschnitt einzufügen, um den Timeout festzulegen, gibt aber keine spezifischen Anweisungen, wie dies geschehen soll. Ich bin mit YAML, Pups und Yarn nicht sehr vertraut oder wie diese in Discourse verwendet werden, daher wollte ich nicht raten. Stattdessen habe ich diese Änderung am ursprünglichen Abschnitt versucht:

  - exec:
      cd: $home
      hook: yarn
      cmd:
        - |
          if [ "$version" != "tests-passed" ]; then
            rm -rf app/assets/javascripts/node_modules
          fi
        - su discourse -c 'yarn config set network-timeout 600000 -g &amp;&amp; yarn install --frozen-lockfile &amp;&amp; yarn cache clean'

Der Befehl ./launcher rebuild app dauert nun sehr lange (über zwei Stunden!, viel länger als früher). Die gute Nachricht ist, dass das Forum wieder online ist! Großartig, danke für die Hilfe.

Gibt es eine Möglichkeit, den Timeout zu erhöhen, indem ein Befehl zu containers/app.yml hinzugefügt wird? Das wäre praktisch, da so alle meine Anpassungen in einer einzigen Datei zusammengefasst wären.

Die Verwendung eines 2-Container-Setups klingt nach einer großartigen Idee; ich war mir nicht bewusst, dass dies möglich ist. Ich nehme an, Sie beziehen sich auf dies: Move from standalone container to separate web and data containers; ich werde es ausprobieren. Zusätzliche Ratschläge sind willkommen.

Wenn ich ein Update meiner Discourse-Instanz über den Browser durchführe, wird dann auch ./launcher rebuild app ausgeführt? Wird das Forum dabei vorübergehend offline genommen? Bisher hatte ich den Eindruck, dass das Forum während des größten Teils des Prozesses online bleibt, aber ich bin mir nicht sicher. Diese Dinge waren mir nie klar, und ich hatte nie die Zeit, sie wirklich herauszufinden. Antworten oder Hinweise auf weitere Informationen sind willkommen.

1 „Gefällt mir“