Error during rebuild: registry.yarnpkg.com ESOCKETTIMEDOUT

installation
1

I am running a self-hosted instance of Discourse at https://forum.embeetle.com.

Yesterday, the one-click browser upgrade failed, so I logged in to the server and tried ./launcher rebuild app.

This failed too, with the following 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)

After this, the command seems to hang (nothing happens for at least 10 minutes) so I killed it and tried again. Same result.

There is no networking problem: from within the docker container (./launcher enter app), running wget https://registry.yarnpkg.com/date-fns/-/date-fns-3.6.0.tgz returns successfully in less than 0.1 seconds.

I checked this similar issue: Error during the update ESOCKETTIMEDOUT registry.yarnpkg.com - #4 by jericson The suggestion there is to increase the timeout by editing /var/discourse/templates/web.template.yml.

Unfortunately, that path does not exist in my installation (from within the docker container, there is no /var/discourse; there is a folder var/www/discourse which is the default working directory when entering the app, but that does not have a templates subfolder; I searched for web.template.yml but could not find it anywhere.

I am also not very confident that increasing the timeout would fix the issue, given the very fast download of https://registry.yarnpkg.com/date-fns/-/date-fns-3.6.0.tgz.

I ended up restoring a backup from a few days ago, with an older version of discourse, and copying the most recent version of discourse/shared into it. This works, so the forum is up and running again.

Is something wrong with the latest version on the main branch? I actually tried running ./launcher rebuild app again, and it fails again in the same way, so I had to restore the forum from backup again.

1 Like
2

I believe the problem isn’t getting the individual packages, but the total time it takes to install them all. If you don’t have enough memory, you can have the problem even if your network speed is fine. The E2.Micro instance I had the problem with has just 1 GB of memory.

For what it’s worth, I just updated Discourse on a 4GB Droplet and didn’t see any particular problems.

3

I am using a VPS with 32GB RAM, currently 24GB free; so memory shouldn’t be an issue.

1 Like
4

You can try

 ./launcher start app

to get the old container running again.
That doesn’t solve the problem but should get your site up again. You shouldn’t need to restore from backup.

/var/discourse is outside of the container, not inside. That template is what builds the stuff in the container, so that’s worth a try.

Also, with as much RAM as you have, I’d switch to 2-container setup so that you can bootstrap without taking your site down.

1 Like
5

Unfortunately, simply running

./launcher start app

doesn’t bring the forum back up.

Anyway, I did further experiments. Specifically, I tried to manually execute the failing yarn command in the docker image:

./launcher enter app
cd /var/www/discourse
su discourse
yarn install --frozen-lockfile
... fails with the same timeout ...
yarn config set network-timeout 600000 -g
yarn install --frozen-lockfile
... succeeds ...

This confirms that increasing the timeout fixes the problem.

The remaining question then is how to also increase the timeout during ./launcher rebuild app.

The file web.template.yml is indeed located in discourse/containers outside of the docker image. I did not find it initially, because my Discourse installation is in a non-standard location, not in /var/discourse.

The fix mentioned in the post referenced above refers to line 159, but that no longer seems correct, probably due to updates. There are however these lines around line 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 && yarn cache clean'

The post suggests to insert a new section to set the timeout, but does not give specific instructions on how to do that. I am not very familiar with yaml, pups and yarn or how these are used in Discourse, so I didn’t want to guess. Instead, I tried this change to the original section:

  - 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 && yarn install --frozen-lockfile && yarn cache clean'

The ./launcher rebuild app command now takes a very long time (more than two hours!, much longer than it used to take), The good news is that the forum is back online! Great, thanks for the help.

Is there a way to increase the timeout by adding a command to containers/app.yml? That would be convenient, as it would keep all my customisations together in a single file.

Using a 2-container setup sounds like a great idea; I was not aware that this is possible. I guess you are referring to this: Move from standalone container to separate web and data containers; I will try it out. Any additional advice is welcome.

When I run an update of my Discourse instance from the browser, does it also run ./launcher rebuild app? Does it temporarily take the forum down? UNtil now, I had the impression that the forum remains online during most of the process, but I am not sure. These things have never been clear to me, and I never had the time to really figure them out. Any answers or pointers to more information are welcome.

1 Like