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

FYI The last version of NodeJS (20.4.0) should resolve this (via https://github.com/nodejs/node/pull/48618) The PR to deploy the docker image has been merged a few minutes ago. It should be available soon. https://github.com/nodejs/docker-node/pull/1937 and https://github.com/docker-library/official-images/pull/14997

FYI a fix for broader number of kernel versions has landed in libuv: https://github.com/libuv/libuv/pull/4141. Still needs to make it into a release and then land it in node.js.

I’m running on my Mac M1 - macOS Ventura 13.5, Node 23.0 and I solved this error by updating my Docker Desktop to v4.23.0.

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.

FWIW, that specific libuv commit is not yet in any release so it didn’t get to Node.js. Also, the fs sync operations aren’t io_uring backed.

FYI there is another case of people hitting this problem here: https://github.com/evanw/esbuild/issues/3156.

The actual kernel version used within the containers is 5.19.2.

This is actually useful. 5.19.x is not a LTS branch from the kernel so lots of io_uring fixes probably won’t get there. In fact I’ve checked with the latest one 5.19.17 and exhibits the same problem. I’ll create a libuv patch for this. Thanks!

I still get this problem with NodeJS 20.4.0

My log:

> node -v  
v20.4.0

> yarn build
yarn run v1.22.19
$ NODE_ENV=production yarn build:webpack
$ webpack
env: can't execute 'node': Text file busy
error Command failed with exit code 126.

Hi! Just tried out @drackp2m solution, and worked fine. I m running a Apple M1 Max and macOS version 13.4.1. I updated the Dockerfile FROM node:16.16.0-alpine to FROM node:20.2.0-alpine3.18 and worked at first! I do use yarn as package manager.

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.)

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

node:20.9 and node:20-bookworm causes problems

• Ubuntu 23.04 lunar
• kernel 5.17.0-1003-oem

I mean, I know, that in version 20.3, what threw the Text file busy error was the husky install command in my package.json, however, for node version 20.5, the error is completely different.

@drackp2m that seems an unrelated issue. Can you open a new issue with all the details and, if possible, a simple reproducer? Thanks!

Thanks for the heads up @CodeNameNinja,

however, keep in mind, that using major versions when specifying your Docker image, can give you problems, always use the latest version of the “18” branch, it could give problems.

Precisely, as it happened to me when moving from 20.2 to 20.3. No need to go so far back in time, if you define in your Dockerfile or docker-compose.yml the version node:20.2-alpine3.17, it should also work for you.

❤️

FWIW we had this issue with Node 20.3.0 and the problem is gone in 20.5.0, kernel 5.13.0.

@drackp2m that’s weird because for that kernel version, io_uring should be disabled. Can you run your code with UV_USE_IO_URING=0 to see if the Text file busy error disappears?

If the kernel of the host is still 5.19.x is normal it’s still failing. I’ll update this issue once the fix lands in libuv and then in nodejs. If the kernel version is different, please post it here so we can keep track of it.

I tried again today with node:20.5-alpine3.17 and things seem to be working, assuming I’ve done everything the same as I did 3+ weeks ago.

I just tried the same version in our minimal test case, but, unfortunately, the pipeline still fails with the same error env: can't execute 'node': Text file busy.

I tried again today with node:20.5-alpine3.17 and things seem to be working, assuming I’ve done everything the same as I did 3+ weeks ago.

I confirm that the same thing happens to me on my Mac Book Air M2 if I start from node:20-alpine3.17

node:20.2.0-alpine3.18 works!

@drackp2m That tag does not work for me. I wonder what the difference is? Does your build process use yarn?

Yes, I use Yarn. You can see an example of my project configuration here: https://github.com/drackp2m/set-online

I confirm that the same thing happens to me on my Mac Book Air M2 if I start from node:20-alpine3.17

node:20.2.0-alpine3.18 works!

@drackp2m That tag does not work for me. I wonder what the difference is? Does your build process use yarn?

I also see this on an Intel Mac, in addition to my previous Linux comment. (Looks like every previous Mac callout on this thread is apple silicon…)

Client:
 Cloud integration: v1.0.33
 Version:           24.0.2
 API version:       1.43
 Go version:        go1.20.4
 Git commit:        cb74dfc
 Built:             Thu May 25 21:51:16 2023
 OS/Arch:           darwin/amd64
 Context:           desktop-linux

Server: Docker Desktop 4.20.1 (110738)
 Engine:
  Version:          24.0.2
  API version:      1.43 (minimum version 1.12)
  Go version:       go1.20.4
  Git commit:       659604f
  Built:            Thu May 25 21:52:17 2023
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.6.21
  GitCommit:        3dce8eb055cbb6872793272b4f20ed16117344f8
 runc:
  Version:          1.1.7
  GitCommit:        v1.1.7-0-g860f061
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

Hi! I faced this issue too. In my case, it was upgrade node from 20.0-bullseye-slim to 20.3.0-bullseye-slim.

Mac M2, Version 13.4.1 (22F82)

docker --version
Docker version 23.0.4, build f480fb1e37

I had a same issue with node:slim and node:20-slim.

Solution: Changing to node:18-slim or node:16-slim worked.

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.

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