Error durante la reconstrucción: registry.yarnpkg.com ESOCKETTIMEDOUT

Instalación
1

Estoy ejecutando una instancia autoalojada de Discourse en https://forum.embeetle.com.

Ayer, la actualización del navegador con un solo clic falló, así que inicié sesión en el servidor y probé ./launcher rebuild app.

Esto también falló, con el siguiente error:

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)

Después de esto, el comando parece colgarse (no pasa nada durante al menos 10 minutos), así que lo maté y lo intenté de nuevo. Mismo resultado.

No hay ningún problema de red: desde dentro del contenedor docker (./launcher enter app), ejecutar wget https://registry.yarnpkg.com/date-fns/-/date-fns-3.6.0.tgz devuelve éxito en menos de 0.1 segundos.

Verifiqué este problema similar: Error during the update ESOCKETTIMEDOUT registry.yarnpkg.com - #4 by jericson La sugerencia allí es aumentar el tiempo de espera editando /var/discourse/templates/web.template.yml.

Desafortunadamente, esa ruta no existe en mi instalación (desde dentro del contenedor docker, no hay /var/discourse; hay una carpeta var/www/discourse que es el directorio de trabajo predeterminado al entrar en la aplicación, pero esa no tiene una subcarpeta templates; busqué web.template.yml pero no pude encontrarla en ninguna parte.

Tampoco estoy muy seguro de que aumentar el tiempo de espera solucione el problema, dada la descarga muy rápida de https://registry.yarnpkg.com/date-fns/-/date-fns-3.6.0.tgz.

Terminé restaurando una copia de seguridad de hace unos días, con una versión anterior de discourse, y copiando la versión más reciente de discourse/shared en ella. Esto funciona, por lo que el foro está en funcionamiento nuevamente.

¿Hay algo malo con la última versión en la rama principal? De hecho, intenté ejecutar ./launcher rebuild app de nuevo, y falla de nuevo de la misma manera, así que tuve que restaurar el foro de la copia de seguridad nuevamente.

1 me gusta
2

Creo que el problema no es la obtención de los paquetes individuales, sino el tiempo total que se tarda en instalarlos todos. Si no tienes suficiente memoria, puedes tener el problema incluso si tu velocidad de red es buena. La instancia E2.Micro con la que tuve el problema tiene solo 1 GB de memoria.

Por si sirve de algo, acabo de actualizar Discourse en un Droplet de 4 GB y no he visto ningún problema en particular.

3

Estoy usando un VPS con 32 GB de RAM, actualmente 24 GB libres; así que la memoria no debería ser un problema.

1 me gusta
4

Puedes intentar

 ./launcher start app

para que el contenedor antiguo vuelva a funcionar.
Eso no resuelve el problema, pero debería hacer que tu sitio vuelva a estar en funcionamiento. No deberías necesitar restaurar desde una copia de seguridad.

/var/discourse está fuera del contenedor, no dentro. Esa plantilla es lo que construye las cosas en el contenedor, así que vale la pena intentarlo.

Además, con tanta RAM como tienes, cambiaría a una configuración de 2 contenedores para que puedas arrancar sin desconectar tu sitio.

1 me gusta
5

Lamentablemente, simplemente ejecutar

./launcher start app

no vuelve a poner el foro en línea.

De todos modos, hice más experimentos. Específicamente, intenté ejecutar manualmente el comando yarn fallido en la imagen de docker:

./launcher enter app
cd /var/www/discourse
su discourse
yarn install --frozen-lockfile
... falla con el mismo timeout ...
yarn config set network-timeout 600000 -g
yarn install --frozen-lockfile
... tiene éxito ...

Esto confirma que aumentar el timeout soluciona el problema.

La pregunta restante entonces es cómo aumentar también el timeout durante ./launcher rebuild app.

El archivo web.template.yml se encuentra efectivamente en discourse/containers fuera de la imagen de docker. No lo encontré inicialmente, porque mi instalación de Discourse está en una ubicación no estándar, no en /var/discourse.

La corrección mencionada en la publicación referenciada anteriormente se refiere a la línea 159, pero esa línea ya no parece ser correcta, probablemente debido a actualizaciones. Sin embargo, hay estas líneas alrededor de la línea 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'

La publicación sugiere insertar una nueva sección para establecer el timeout, pero no da instrucciones específicas sobre cómo hacerlo. No estoy muy familiarizado con yaml, pups y yarn o cómo se usan en Discourse, así que no quise adivinar. En cambio, probé este cambio en la sección original:

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

El comando ./launcher rebuild app ahora tarda mucho tiempo (¡más de dos horas!, mucho más de lo que solía tardar). La buena noticia es que el foro está de vuelta en línea. Genial, gracias por la ayuda.

¿Hay alguna forma de aumentar el timeout añadiendo un comando a containers/app.yml? Sería conveniente, ya que mantendría todas mis personalizaciones juntas en un solo archivo.

Usar una configuración de 2 contenedores suena como una gran idea; no era consciente de que esto fuera posible. Supongo que te refieres a esto: Move from standalone container to separate web and data containers; lo probaré. Cualquier consejo adicional es bienvenido.

Cuando ejecuto una actualización de mi instancia de Discourse desde el navegador, ¿también ejecuta ./launcher rebuild app? ¿Toma temporalmente el foro? Hasta ahora, tenía la impresión de que el foro permanece en línea durante la mayor parte del proceso, pero no estoy seguro. Estas cosas nunca han estado claras para mí, y nunca he tenido tiempo de averiguarlas realmente. Cualquier respuesta o indicación de más información es bienvenida.

1 me gusta