You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Node 20.3.0 images give error /usr/bin/env: 'node': Text file busy #1912
> [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?
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:
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.
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.
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.)
Reacted by Joost Koehoorn, Zephyr Lykos and Jay Graves
Experiencing same issue here, but downgrading to node:20-alpine3.16 seems to have fixed it. Seems the issue reappears for us in 20-alpine3.17 (which includes Node 20.3.0) - perhaps (guessing here) it's related to a line in the changelog for Node v20.3.0 which says:
[bfcb3d1d9a] - deps: upgrade to libuv 1.45.0, including significant performance improvements to file system operations on Linux (Santiago Gimeno) nodejs/node#48078
(which does backup what @ahamlinman mentioned above)
Workaround to avoid downgrading the kernel:
UV_USE_IO_URING=0 your_command_using_node
Ex: UV_USE_IO_URING=0 yarn dev
Reacted by Yiwen Yang, Daniel, giskard, jakubko223, Jan Kvapil, Dark Hole, JHT, Ignacio Benedetti, Edgar Arturo Ramos Rambaud, Alejandro R Buteler and 12 more
Reacted by Maiko Sinkyaet Tan, davemeehan, Ignacio Benedetti, Alejandro R Buteler, Compositr, Jonathan KUMA, Serge Hänni, Felx and d-a-s
For anyone wondering on how to downgrade your arch kernel, you can downgrade to previous installations (of any package) from chache: pacman -U /var/cache/pacman/pkg/linux-<your-version>.pkg.tar.zst
This issue from 2023 attracted a lot of activity which however stopped in 2024, 2 years ago. I'm going to suggest closing it now for the following reasons:
Later comments in the discussion thread also referred to Arch Linux, which this repo is not specifically involved in.
It does not appear that there is any ongoing issue that could be fixed here. Keeping the issue open would only be helpful if there is something that needs to be changed in the Docker build process in this repo.
Activity
culli commentedon Jun 12, 2023
I can provide a more complete repro node project if that is needed.
danlordan commentedon Jun 13, 2023
+1, getting an issue on this as well, had to switch to
node:18to get builds to run, instead ofnode:latestEeemil commentedon Jun 14, 2023
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 commentedon Jun 14, 2023
Can (temporarily) be fixed by using OrbStack instead of Docker for Mac
mfn commentedon Jun 14, 2023
Same here with
node:20.3-slimrunning in Docker Desktop 4.20.1 on macOS 13.4 Apple Silicon.Reverting to
node:20.2-slimworked.Only affected shell/bash scripts trying to start node (e.g.
yarn startin 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 commentedon Jun 14, 2023
Can confirm I got this issue on M1 mac and Pop!_os
bjonnh-work commentedon Jun 14, 2023
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 commentedon Jun 14, 2023
This issue was also observed in the following environments:
node:20-alpineIt 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 withnode:18-alpineworks.However, this problem does not occur in the following environments:
jerlendds commentedon Jun 15, 2023
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 commentedon Jun 15, 2023
FYI there is another case of people hitting this problem here: evanw/esbuild#3156.
JoostK commentedon Jun 15, 2023
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 commentedon Jun 15, 2023
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.
featherbread commentedon Jun 16, 2023
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=0set 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
stracethat 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(edit: This entire part is incorrect, please see below. Thank you @santigimeno for the correction, I apologize for the error.)fs.renameSync, it might be notable thatrenameis apparently one of the operations now backed by io_uring, per libuv/libuv#4012 (my guess is that the*Syncfunctions 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.harvey-appleton commentedon Jun 16, 2023
Experiencing same issue here, but downgrading to
node:20-alpine3.16seems to have fixed it. Seems the issue reappears for us in20-alpine3.17(which includes Node 20.3.0) - perhaps (guessing here) it's related to a line in the changelog for Node v20.3.0 which says:(which does backup what @ahamlinman mentioned above)
mgattei commentedon Jun 16, 2023
Same here for a pipeline that run semantic-release. Gitlab - node:alpine
Error:
By retrying several times, it seems to work after a while.... I solved the problem temporarily by downgrading to an older node image.
73 remaining items
FLX-0x00 commentedon May 26, 2024
Cant get this working with arch linux 6.9.1-arch. tried nodejs-lts-hydrogen 18.20, nodejs-lts-iron 20.13 or nodejs 22.2
is0ly commentedon May 26, 2024
yarn set version stableyarn installfrom yarn site - fixed this wired behavior without switching kernel version
felixonmars commentedon May 26, 2024
Please try Arch Linux's new kernel 6.9.2-1 and see if it makes a difference.
FLX-0x00 commentedon May 26, 2024
Still the same error even with new kernel after reboot. Switched to the linux-lts kernel.
MartinX3 commentedon May 27, 2024
At my side it got fixed with the upgrade from pnpm 9.1.2 to 9.1.3.
And I also use the 6.9.2 kernel now.
I don't know if the fix is in any of these commits or it is just coincidence:
pnpm/pnpm@v9.1.2...v9.1.3
zguig52 commentedon May 27, 2024
Workaround to avoid downgrading the kernel:
UV_USE_IO_URING=0 your_command_using_node
Ex: UV_USE_IO_URING=0 yarn dev
ZulluBalti commentedon May 28, 2024
I think it's a coincident as I"m also using pnpm version 9.1.3 with kernel 6.9.2-arch1-1 and still getting this error
ZulluBalti commentedon May 28, 2024
Nope, it doesn't make any difference still getting this error with 6.9.2-1
MartinX3 commentedon May 28, 2024
@ZulluBalti woopsi.
You're right.
After a computer restart the issue reappeared at my site as well.
skabber commentedon May 28, 2024
Same error
/usr/bin/env: ‘node’: Text file busyusing nixos kernel 6.9.2. Backing out to 6.8.11 fixes the issue.mzndr commentedon May 29, 2024
For anyone wondering on how to downgrade your arch kernel, you can downgrade to previous installations (of any package) from chache:
pacman -U /var/cache/pacman/pkg/linux-<your-version>.pkg.tar.zstskabber commentedon May 29, 2024
Here is the issue tracked on nodejs/node nodejs/node#53051
MikeMcC399 commentedon May 3, 2026
This issue from 2023 attracted a lot of activity which however stopped in 2024, 2 years ago. I'm going to suggest closing it now for the following reasons:
Later comments in the discussion thread also referred to Arch Linux, which this repo is not specifically involved in.
It does not appear that there is any ongoing issue that could be fixed here. Keeping the issue open would only be helpful if there is something that needs to be changed in the Docker build process in this repo.
MartinX3 commentedon May 3, 2026
It was fixed with kernel 6.9.3 in june 2024.
Please close this issue.