Errore durante la ricostruzione: registry.yarnpkg.com ESOCKETTIMEDOUT

Sto eseguendo un’istanza self-hosted di Discourse su https://forum.embeetle.com.

Ieri, l’aggiornamento del browser con un clic è fallito, quindi ho effettuato l’accesso al server e ho provato ./launcher rebuild app.

Anche questo è fallito, con il seguente errore:

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)

Dopo questo, il comando sembra bloccarsi (non succede nulla per almeno 10 minuti), quindi l’ho interrotto e ho riprovato. Stesso risultato.

Non ci sono problemi di rete: dall’interno del container Docker (./launcher enter app), l’esecuzione di wget https://registry.yarnpkg.com/date-fns/-/date-fns-3.6.0.tgz restituisce correttamente in meno di 0,1 secondi.

Ho controllato questo problema simile: Error during the update ESOCKETTIMEDOUT registry.yarnpkg.com - #4 by jericson Il suggerimento lì è di aumentare il timeout modificando /var/discourse/templates/web.template.yml.

Sfortunatamente, quel percorso non esiste nella mia installazione (dall’interno del container Docker, non c’è /var/discourse; c’è una cartella var/www/discourse che è la directory di lavoro predefinita quando si entra nell’app, ma quella non ha una sottocartella templates; ho cercato web.template.yml ma non sono riuscito a trovarlo da nessuna parte.

Inoltre, non sono molto convinto che aumentare il timeout risolverebbe il problema, data la velocità di download di https://registry.yarnpkg.com/date-fns/-/date-fns-3.6.0.tgz.

Alla fine ho ripristinato un backup di qualche giorno fa, con una versione precedente di Discourse, e ho copiato la versione più recente di discourse/shared al suo interno. Questo funziona, quindi il forum è di nuovo attivo e funzionante.

C’è qualcosa che non va nell’ultima versione sul branch principale? Ho effettivamente provato a eseguire di nuovo ./launcher rebuild app, e fallisce di nuovo nello stesso modo, quindi ho dovuto ripristinare il forum dal backup.

1 Mi Piace

Credo che il problema non sia ottenere i singoli pacchetti, ma il tempo totale necessario per installarli tutti. Se non hai abbastanza memoria, puoi avere il problema anche se la tua velocità di rete è buona. L’istanza E2.Micro con cui ho avuto il problema ha solo 1 GB di memoria.

Per quello che vale, ho appena aggiornato Discourse su un Droplet da 4 GB e non ho riscontrato problemi particolari.

Sto usando un VPS con 32 GB di RAM, attualmente 24 GB liberi; quindi la memoria non dovrebbe essere un problema.

1 Mi Piace

Puoi provare

 ./launcher start app

per rimettere in funzione il vecchio container.
Questo non risolve il problema, ma dovrebbe ripristinare il tuo sito. Non dovresti aver bisogno di ripristinare dal backup.

/var/discourse è al di fuori del container, non all’interno. Quel template è ciò che costruisce le cose nel container, quindi vale la pena provare.

Inoltre, con tutta la RAM che hai, passerei a una configurazione a 2 container in modo da poter avviare senza mettere giù il tuo sito.

1 Mi Piace

Purtroppo, eseguire semplicemente

./launcher start app

non ripristina il forum.

Comunque, ho fatto ulteriori esperimenti. Nello specifico, ho provato a eseguire manualmente il comando yarn fallito nell’immagine docker:

./launcher enter app
cd /var/www/discourse
su discourse
yarn install --frozen-lockfile
... fallisce con lo stesso timeout ...
yarn config set network-timeout 600000 -g
yarn install --frozen-lockfile
... riesce ...

Questo conferma che aumentare il timeout risolve il problema.

La domanda rimanente è quindi come aumentare anche il timeout durante ./launcher rebuild app.

Il file web.template.yml si trova effettivamente in discourse/containers al di fuori dell’immagine docker. Non l’ho trovato inizialmente, perché la mia installazione di Discourse si trova in una posizione non standard, non in /var/discourse.

La correzione menzionata nel post a cui si fa riferimento si riferisce alla riga 159, ma questa non sembra più corretta, probabilmente a causa degli aggiornamenti. Ci sono tuttavia queste righe intorno alla riga 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'

Il post suggerisce di inserire una nuova sezione per impostare il timeout, ma non fornisce istruzioni specifiche su come farlo. Non ho molta familiarità con yaml, pups e yarn o con il loro utilizzo in Discourse, quindi non ho voluto indovinare. Invece, ho provato questa modifica alla sezione originale:

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

Il comando ./launcher rebuild app ora richiede molto tempo (più di due ore!, molto più tempo di quanto impiegasse in precedenza). La buona notizia è che il forum è di nuovo online! Ottimo, grazie per l’aiuto.

C’è un modo per aumentare il timeout aggiungendo un comando a containers/app.yml? Sarebbe conveniente, poiché manterrebbe tutte le mie personalizzazioni in un unico file.

L’utilizzo di una configurazione a 2 container sembra un’ottima idea; non ero a conoscenza della sua possibilità. Immagino ti riferisca a questo: Move from standalone container to separate web and data containers; ci proverò. Qualsiasi consiglio aggiuntivo è benvenuto.

Quando eseguo un aggiornamento della mia istanza Discourse dal browser, esegue anche ./launcher rebuild app? Mette temporaneamente offline il forum? Finora, avevo l’impressione che il forum rimanesse online durante la maggior parte del processo, ma non ne sono sicuro. Queste cose non mi sono mai state chiare e non ho mai avuto il tempo di capirle veramente. Qualsiasi risposta o indicazione per ulteriori informazioni è benvenuta.

1 Mi Piace