Upgraded OpenWA and now it's not working

[TechBreakHelp]

Hi, I recently upgraded to last version of OpenWA (v0.23.3) in my server Ubuntu 20.04.

I fired
git pull
npm ci
npm run dev

When the instance of OpenWA is loading it ends up with this error:
[api] [Nest] 1899790 - 08/25/2026, 6:34:22 PM ERROR [ExceptionHandler] Error: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by /var/www/html/sub.domain.com/html/OpenWA/node_modules/better-sqlite3/prebuilds/linux-x64.node)

Tried to npm rebuild better-sqlite3 --build-from-source, but nothing has changed. Any ideas how to fix and run again OpenWA?

[rmyndharis]

This is a glibc floor rather than an OpenWA bug, and it landed in v0.19.0, not v0.23.3.

v0.19.0 moved the SQLite driver from better-sqlite3 12 to 13. v12 fetched or compiled its native binary at install time. v13 ships prebuilt binaries inside the package, and the Linux x64 one is linked against glibc 2.34:

$ strings node_modules/better-sqlite3/prebuilds/linux-x64.node | grep -o 'GLIBC_[0-9.]*' | sort -uV
GLIBC_2.2.5
GLIBC_2.3
GLIBC_2.3.4
GLIBC_2.4
GLIBC_2.14
GLIBC_2.28
GLIBC_2.29
GLIBC_2.33
GLIBC_2.34

Ubuntu 20.04 ships glibc 2.31, so the binary cannot load. The error names 2.33 only because that is the first unresolvable symbol version the loader hits. The effective minimum is now Ubuntu 22.04, Debian 12, or RHEL 9. The Docker image is unaffected: it is based on node:22-slim (Debian bookworm, glibc 2.36).

npm rebuild better-sqlite3 --build-from-source is a no-op here, for two separate reasons:

1. --build-from-source is a prebuild-install flag. better-sqlite3 13 dropped prebuild-install, so nothing reads it. Its binding.gyp compiles only when force_build==1 or prebuild_exists==0, and the bundled prebuild sets prebuild_exists to 1, so the target resolves to 'type': 'none' and nothing is built.
2. Even if it did compile, lib/binding.js probes prebuilds/<platform>-<arch>.node before build/Release/better_sqlite3.node, so a freshly built binary would never be loaded.

One more thing worth knowing: switching to PostgreSQL does not avoid this. The auth and audit connection is always SQLite regardless of DATABASE_TYPE, so better-sqlite3 is loaded on every boot.

Options, in the order I would try them:

1. Run the Docker image. glibc 2.36, unaffected.

2. Move to Ubuntu 22.04 or newer. 20.04 left standard support in April 2025.

3. Compile locally, if you need to stay on 20.04. Remove the prebuild so the loader falls through to build/Release, then force a build. Ubuntu 20.04's default g++ 9 does not accept -std=c++20, so install g++ 10 or newer first:

sudo apt install -y build-essential python3 g++-10
cd node_modules/better-sqlite3
rm prebuilds/linux-x64.node
CC=gcc-10 CXX=g++-10 npm run build-release

Note that any later npm ci or npm install reinstalls the package and restores the prebuild, so this has to be repeated each time. It is a workaround, not a fix.

[TechBreakHelp]

Many thanks for your answer, I was able to launch OpenWA into my server with the third option, just to be online ASAP. I will schedule an upgrade of Ubuntu. Cannot use docker due to limited resources of the server.

[MLuc24]

Ubuntu 20.04 ships glibc 2.31, and that prebuilt binary wants 2.33 — so it can never load on that host, no matter what else you change. Worth confirming with ldd --version before anything else, just to have the number in front of you.

The reason your rebuild appeared to do nothing is worth understanding, because it is easy to run the command and get a clean exit while nothing was compiled. --build-from-source is the node-pre-gyp spelling; better-sqlite3 (you are on ^13.0.3) uses prebuild-install, and the loader keeps reaching for prebuilds/ unless a real compiled artefact exists. So the thing to check is whether this file appeared:

node_modules/better-sqlite3/build/Release/better_sqlite3.node

If it did not, the compile never happened — usually because the toolchain is missing rather than because it failed loudly:

sudo apt install -y build-essential python3
npm install better-sqlite3 --build-from-source

then look for that file again. If you want to be certain nothing can fall back, delete node_modules/better-sqlite3/prebuilds/ afterwards so there is no prebuild left to pick.

One thing to know before you settle on that as the fix: npm ci deletes node_modules outright and reinstalls from the lockfile, so it will restore the prebuild and undo the compile every time you deploy. And nothing in the project does it for you — I looked through scripts/postinstall.js, and its steps are the dashboard install and the whatsapp-web.js patchers, with no native rebuild among them. So a source build has to be part of your deploy sequence rather than a one-off repair.

Given that, the durable answer is probably the host rather than the module. package.json declares "engines": { "node": ">=22.13" }, and 20.04 is past its standard support window, so you are running a current Node and current native dependencies against an old libc — this class of breakage will keep recurring as other packages refresh their prebuild toolchains. A newer base image, or the project's Docker path, sidesteps it entirely rather than one package at a time.