Node 20.3.0 images give error `/usr/bin/env: 'node': Text file busy`

[culli]

Environment

• Platform: macos 13.4 M1
• Docker Version: 24.0.2
• Node.js Version: 20.3.0
• Image Tag: node:20-alpine3.17

Expected Behavior

yarn tsc should run correctly

Current Behavior

 > [service 5/5] RUN yarn build:
#0 0.298 yarn run v1.22.19
#0 0.314 $ tsc
#0 0.325 /usr/bin/env: 'node': Text file busy
#0 0.334 error Command failed with exit code 126.

Possible Solution

downgrade to node:20-alpine3.16 (or node:20.2.0-bullseye-slim)

Steps to Reproduce

dockerfile:

FROM node:20-alpine3.17 as install
WORKDIR /service
COPY ./service ./
RUN yarn install --frozen-lockfile
RUN yarn build

yarn build creates a directory, compiles some protobuf, then execs tsc (bin from typescript dependency)

Additional Information

Things work correctly on 3.16, but give the text file busy error with 3.17 and 3.18. Also tried bullseye-slim and node:20.3.0-bullseye-slim gives the same error, but 20.2.0 works correctly.

Maybe this is an architecture mismatch or file permissions problem?

[culli]

I can provide a more complete repro node project if that is needed.

[danlordan]

+1, getting an issue on this as well, had to switch to node:18 to get builds to run, instead of node:latest

[Eeemil]

A colleague of mine running a Mac M1 has the same issue, but it works for me on PC (Ubuntu). Might be an issue for Mac M1 only.

[egl74]

Can (temporarily) be fixed by using OrbStack instead of Docker for Mac

[mfn]

Same here with node:20.3-slim running in Docker Desktop 4.20.1 on macOS 13.4 Apple Silicon.

Reverting to node:20.2-slim worked.

Only affected shell/bash scripts trying to start node (e.g. yarn start in a NextJS project), when I ran it manually it worked.

Only saw this on local dev and not pro container (but prod != ARM, so… 🤷🏼 )

[yann1731]

A colleague of mine running a Mac M1 has the same issue, but it works for me on PC (Ubuntu). Might be an issue for Mac M1 only.

Can confirm I got this issue on M1 mac and Pop!_os

[bjonnh-work]

This is breaking in docker on x86 as well as M1 for us, and we get the same error on containers that start yarn.

[book000]

This issue was also observed in the following environments:

• Windows 10 22H2 (Build 19045.2965)
• CPU: AMD Ryzen 9 5900X (x86_64)
• Docker Desktop 4.19.0 (106363)
• Image tag: node:20-alpine
• Package manager: Yarn

It is not limited to a specific Node.js project, but occurs in all projects that use node:20-alpine. I have confirmed that replacing it with node:18-alpine works.

---

However, this problem does not occur in the following environments:

• Ubuntu 22.04.2 LTS
• CPU: Intel Core i7-6700 (x86_64)
• Docker 24.0.2

[jerlendds]

This can be recreated in my project from commit b76bc9b with the frontend Dockerfile but I have since pushed this version: node:18-alpine.

Seemingly related: Docker forums
My related issue with more details can be found here: jerlendds/osintbuddy#49

[evanw]

FYI there is another case of people hitting this problem here: evanw/esbuild#3156.

[JoostK]

Sharing an additional data point here as well (from evanw/esbuild#3156 (comment)): the issue only reproduces for me using Docker Engine 24, whereas the image works fine using Docker Engine 20. Tested on M1 Max.

[GabeDuarteM]

This was also happening with me and all my coworkers that use mac for development.

The "solution" we found for now was to use OrbStack instead, it's a drop-in replacement for docker desktop, and seems to solve this problem. While not ideal, it did unblock us while we wait for the official solution.

[ahamlinman]

I started looking more closely at the libuv v1.45.0 upgrade after @JoostK mentioned it in the esbuild thread, particularly some of the changes around io_uring support. There is an environment variable (undocumented and unstable, intended for debugging purposes only) to disable libuv's use of io_uring, and with UV_USE_IO_URING=0 set in my container's environment I can no longer reproduce the issue during esbuild installs with any of the Node.js v20.3.0 image variants I've tested (M1 Max, Docker Desktop v4.20.1, Docker Engine v24.0.2).

I also have an Arch Linux ARM virtual machine on my Mac separate from Docker Desktop, and tried building and installing libuv v1.45.0 there. In that case, I couldn't reproduce the same issue during an esbuild install, even though I could confirm with strace that Node.js was dispatching io_uring operations. That makes me wonder if the kernel version is partly at play (6.3.7 on my Arch VM vs. 5.15.49-linuxkit-pr in the Docker VM). (edit: I set up a separate system with a separate build of Linux 5.15.49, and couldn't reproduce either on the system or with the Docker images. Looking at kernel versions alone may not be a useful lead.)

Given @evanw's note in the original thread about possible changes to fs.renameSync, it might be notable that rename is apparently one of the operations now backed by io_uring, per libuv/libuv#4012 (my guess is that the *Sync functions in Node.js still use libuv under the hood, but I'm not certain). If that really is where this comes from, the discussion may ultimately belong with libuv, or even with Node.js if it's somehow particular to Node's usage of libuv. (edit: This entire part is incorrect, please see below. Thank you @santigimeno for the correction, I apologize for the error.)