Erreur lors de la reconstruction : registry.yarnpkg.com ESOCKETTIMEDOUT

Installation
1

J’exécute une instance auto-hébergée de Discourse sur https://forum.embeetle.com.

Hier, la mise à niveau du navigateur en un clic a échoué, j’ai donc accédé au serveur et j’ai essayé ./launcher rebuild app.

Cela a également échoué, avec l’erreur suivante :

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)

Après cela, la commande semble se bloquer (rien ne se passe pendant au moins 10 minutes), je l’ai donc interrompue et j’ai réessayé. Même résultat.

Il n’y a pas de problème de réseau : depuis l’intérieur du conteneur Docker (./launcher enter app), exécuter wget https://registry.yarnpkg.com/date-fns/-/date-fns-3.6.0.tgz renvoie un succès en moins de 0,1 seconde.

J’ai vérifié ce problème similaire : Error during the update ESOCKETTIMEDOUT registry.yarnpkg.com - #4 by jericson La suggestion est d’augmenter le délai d’attente en modifiant /var/discourse/templates/web.template.yml.

Malheureusement, ce chemin n’existe pas dans mon installation (depuis l’intérieur du conteneur Docker, il n’y a pas de /var/discourse; il y a un dossier var/www/discourse qui est le répertoire de travail par défaut lors de l’entrée dans l’application, mais celui-ci n’a pas de sous-dossier templates; j’ai cherché web.template.yml mais je ne l’ai trouvé nulle part.

Je ne suis pas non plus très confiant qu’augmenter le délai d’attente résoudrait le problème, étant donné le téléchargement très rapide de https://registry.yarnpkg.com/date-fns/-/date-fns-3.6.0.tgz.

J’ai fini par restaurer une sauvegarde d’il y a quelques jours, avec une version plus ancienne de Discourse, et en copiant la version la plus récente de discourse/shared dedans. Cela fonctionne, donc le forum est à nouveau opérationnel.

Y a-t-il un problème avec la dernière version de la branche principale ? J’ai en fait essayé de relancer ./launcher rebuild app, et cela échoue à nouveau de la même manière, j’ai donc dû restaurer le forum à partir de la sauvegarde.

1 « J'aime »
2

Je pense que le problème n’est pas l’obtention des paquets individuels, mais le temps total nécessaire pour les installer tous. Si vous n’avez pas assez de mémoire, vous pouvez avoir le problème même si votre vitesse réseau est bonne. L’instance E2.Micro avec laquelle j’ai eu le problème n’a que 1 Go de mémoire.

Pour information, je viens de mettre à jour Discourse sur un Droplet de 4 Go et je n’ai rencontré aucun problème particulier.

3

J’utilise un VPS avec 32 Go de RAM, dont 24 Go sont actuellement libres ; la mémoire ne devrait donc pas poser de problème.

1 « J'aime »
4

[quote=“Johan Cockx, post:1, topic:319714, username:ygramoel”]
Que dois-je faire pour que mon forum soit de nouveau opérationnel ?
[/quote]Vous pouvez essayer

 ./launcher start app

pour relancer l’ancien conteneur.
Cela ne résout pas le problème, mais devrait remettre votre site en ligne. Vous ne devriez pas avoir besoin de restaurer à partir d’une sauvegarde.

/var/discourse est à l’extérieur du conteneur, pas à l’intérieur. Ce modèle est ce qui construit les éléments dans le conteneur, donc cela vaut la peine d’essayer.

De plus, avec autant de RAM que vous avez, je passerais à une configuration à 2 conteneurs afin de pouvoir démarrer sans mettre votre site hors service.

1 « J'aime »
5

Malheureusement, le simple fait d’exécuter

./launcher start app

ne remet pas le forum en ligne.

Quoi qu’il en soit, j’ai mené d’autres expériences. Plus précisément, j’ai essayé d’exécuter manuellement la commande yarn défaillante dans l’image Docker :

./launcher enter app
cd /var/www/discourse
su discourse
yarn install --frozen-lockfile
... échoue avec le même timeout ...
yarn config set network-timeout 600000 -g
yarn install --frozen-lockfile
... réussit ...

Cela confirme que l’augmentation du timeout résout le problème.

La question restante est donc de savoir comment augmenter également le timeout lors de ./launcher rebuild app.

Le fichier web.template.yml est bien situé dans discourse/containers en dehors de l’image Docker. Je ne l’avais pas trouvé initialement, car mon installation Discourse se trouve dans un emplacement non standard, pas dans /var/discourse.

La correction mentionnée dans le post référencé ci-dessus fait référence à la ligne 159, mais cela ne semble plus correct, probablement en raison des mises à jour. Il y a cependant ces lignes autour de la ligne 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'

Le post suggère d’insérer une nouvelle section pour définir le timeout, mais ne donne pas d’instructions précises sur la façon de le faire. Je ne suis pas très familier avec yaml, pups et yarn ou leur utilisation dans Discourse, donc je ne voulais pas deviner. Au lieu de cela, j’ai essayé cette modification de la section d’origine :

  - 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'

La commande ./launcher rebuild app prend maintenant très longtemps (plus de deux heures !, beaucoup plus longtemps qu’avant). La bonne nouvelle est que le forum est de retour en ligne ! Super, merci pour votre aide.

Existe-t-il un moyen d’augmenter le timeout en ajoutant une commande à containers/app.yml ? Ce serait pratique, car cela permettrait de conserver toutes mes personnalisations dans un seul fichier.

L’utilisation d’une configuration à 2 conteneurs semble être une excellente idée ; je n’étais pas au courant que c’était possible. Je suppose que vous faites référence à ceci : Move from standalone container to separate web and data containers ; je vais l’essayer. Tout conseil supplémentaire est le bienvenu.

Lorsque je mets à jour mon instance Discourse depuis le navigateur, exécute-t-il également ./launcher rebuild app ? Met-il temporairement le forum hors ligne ? Jusqu’à présent, j’avais l’impression que le forum restait en ligne pendant la majeure partie du processus, mais je ne suis pas sûr. Ces choses n’ont jamais été claires pour moi, et je n’ai jamais eu le temps de vraiment comprendre. Toutes les réponses ou indications vers plus d’informations sont les bienvenues.

1 « J'aime »