fix: base Docker image on Debian trixie for uWebSockets.js glibc 2.38#564
Open
kriszyp wants to merge 2 commits into
Open
fix: base Docker image on Debian trixie for uWebSockets.js glibc 2.38#564kriszyp wants to merge 2 commits into
kriszyp wants to merge 2 commits into
Conversation
uWebSockets.js v20.68.0 (pinned in #1096 for the HARPER_UWS_UDS / H3 work) ships prebuilt Linux binaries built on GitHub's ubuntu-24.04 runners, which link against GLIBC_2.38. Our image was built on node:24 (Debian bookworm, glibc 2.36), so the addon threw on require() — /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.38' not found (required by .../uWebSockets.js/uws_linux_x64_137.node) — even though #561 correctly got the addon bundled into the image. HARPER_UWS_UDS was therefore inert on any bookworm-based build. Bump the build and run base images to node:24-trixie (Debian 13, glibc 2.41). glibc is forward-compatible, so all other native deps (lmdb, rocksdb-js, msgpackr, argon2, …) built against <=2.36 continue to load unchanged; only the floor is raised to satisfy uWS. Build and run stages move together so from-source addons compiled in the build stage match the run-stage glibc. Verified on the deployed 5.2.0-alpha.3 image (bookworm): the addon is present but fails to load; objdump confirms the binary's max required symbol is GLIBC_2.38 vs the container's 2.36.
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request updates the Dockerfile to use Node.js images based on Debian trixie (24-trixie) to satisfy the GLIBC 2.38 requirement of uWebSockets.js v20.68.0. The reviewer raised valid concerns regarding the stability and security risks of using a Debian testing release in production, suggesting alternatives such as using Ubuntu 24.04 LTS or compiling the native addon from source.
Contributor
|
Reviewed; no blockers found. |
This was referenced Jul 12, 2026
…g the Dockerfile defaults The publish workflow passes NODE_BUILD_VERSION/NODE_VERSION explicitly from its matrix (24/25), which overrode the new 24-trixie Dockerfile defaults — published images would have stayed on bookworm. Also, the default-version tag detection read '24-trixie' from the Dockerfile and compared it to the bare matrix majors, which would have stopped the un-suffixed release tags (x.y.z, x.y, x) from being pushed. Append -trixie to the build-args and strip the variant suffix in the default-version comparison. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Follow-up to #561. That PR correctly got the
uWebSockets.jsnative addon bundled into the image, but the addon still can't load at runtime because of a glibc floor mismatch:uWebSockets.jsv20.68.0 (pinned in #1096 for theHARPER_UWS_UDS/ H3 work) ships prebuilt Linux binaries built on GitHub'subuntu-24.04runners, which link againstGLIBC_2.38. OurDockerfilebuilds onnode:24= Debian bookworm (glibc 2.36). The addon throws onrequire(), soHARPER_UWS_UDSis inert on any bookworm-based build.Fix
Bump the build and run base images
node:24→node:24-trixie(Debian 13, glibc 2.41).glibc is forward-compatible: a binary built against an older glibc runs on a newer one, never the reverse. So raising the floor to 2.41 satisfies uWS's 2.38 requirement while every other native dependency (lmdb, rocksdb-js, msgpackr, argon2, …), all built against ≤2.36, keeps loading unchanged. Build and run stages move together so any from-source addon compiled in the build stage matches the run-stage glibc.
Verification
On the deployed
5.2.0-alpha.3image (bookworm), against the live GPU dev cluster:node_modules/uWebSockets.js/is present with all prebuilt binaries (fix: resolve uWebSockets.js via https, not ssh, in package-lock.json #561 working).require('uWebSockets.js')throws theGLIBC_2.38 not founderror above.ldd (Debian GLIBC 2.36-9+deb12u14) 2.36.objdump -T uws_linux_x64_137.node→ max required symbol versionGLIBC_2.38.Test plan
require('uWebSockets.js')loads (App type isfunction) inside the resulting imageHARPER_UWS_UDSon a dev cluster behind symphony and confirm the uWS backend actually engages — the end-to-end validation #1096 has been blocked on