[BUG] npm 10.9.0 stuck in wsl with ubuntu environment

[Vincere1st]

Is there an existing issue for this?

• I have searched the existing issues

This issue exists in the latest npm version

• I am using the latest npm

Current Behavior

I wanted to prepare a project with vue3 under docker with the node:22.10-alpine image in my WSL environment, and when I launched the npm installation, npm stuck for 7mn.

I specify the wsl environment, because I have a vagrant environment on the same machine, and I don't have the same problem.

So why am I opening the problem here?
Because if I use version 10.8.0, the installation packages won't be blocked.

I've made a minimal repo for testing here: https://github.com/Vincere1st/minimal-repo-npm-10.9.0-stuck-in-wsl-environnement

If you can't test, i join the results of logs, one with npm 10.8.0 and the other for 10.9.0.
npm-10.8.0-logs.txt
npm-10.9.0-logs.txt

Here the time for the installation of this minimal repo with 10.8.0 version:

And with 10.9.0

Expected Behavior

npm install will not stuck with the latest version in wsl environment.

Steps To Reproduce

1. In wsl with docker
2. use my minimal repo here: https://github.com/Vincere1st/minimal-repo-npm-10.9.0-stuck-in-wsl-environnement
3. Follow the readme
4. The logs will be show in the terminal

Environment

• npm: 10.9.0
• Node.js: 22.10 alpine
• OS Name: Ubuntu
• System Model Name: WSL
• npm config:

; "default" config from default values

_auth = (protected)
access = null
all = false
allow-same-version = false
also = null
audit = true
audit-level = null
auth-type = "web"
before = null
bin-links = true
browser = null
ca = null
cache = "/root/.npm"
cache-max = null
cache-min = 0
cafile = null
call = ""
cert = null
cidr = null
color = true
commit-hooks = true
cpu = null
depth = null
description = true
dev = false
diff = []
diff-dst-prefix = "b/"
diff-ignore-all-space = false
diff-name-only = false
diff-no-prefix = false
diff-src-prefix = "a/"
diff-text = false
diff-unified = 3
dry-run = false
editor = "vi"
engine-strict = false
expect-result-count = null
expect-results = null
fetch-retries = 2
fetch-retry-factor = 10
fetch-retry-maxtimeout = 60000
fetch-retry-mintimeout = 10000
fetch-timeout = 300000
force = false
foreground-scripts = false
format-package-lock = true
fund = true
git = "git"
git-tag-version = true
global = false
global-style = false
globalconfig = "/home/node/.npm-global/etc/npmrc"
heading = "npm"
https-proxy = null
if-present = false
ignore-scripts = false
include = []
include-staged = false
include-workspace-root = false
init-author-email = ""
init-author-name = ""
init-author-url = ""
init-license = "ISC"
init-module = "/root/.npm-init.js"
init-version = "1.0.0"
init.author.email = ""
init.author.name = ""
init.author.url = ""
init.license = "ISC"
init.module = "/root/.npm-init.js"
init.version = "1.0.0"
install-links = false
install-strategy = "hoisted"
json = false
key = null
legacy-bundling = false
legacy-peer-deps = false
libc = null
link = false
local-address = null
location = "user"
lockfile-version = null
loglevel = "notice"
logs-dir = null
logs-max = 10
; long = false ; overridden by cli
maxsockets = 15
message = "%s"
node-options = null
noproxy = [""]
npm-version = "10.9.0"
offline = false
omit = []
omit-lockfile-registry-resolved = false
only = null
optional = null
os = null
otp = null
pack-destination = "."
package = []
package-lock = true
package-lock-only = false
parseable = false
prefer-dedupe = false
prefer-offline = false
prefer-online = false
; prefix = "/usr/local" ; overridden by env
preid = ""
production = null
progress = true
provenance = false
provenance-file = null
proxy = null
read-only = false
rebuild-bundle = true
registry = "https://registry.npmjs.org/"
replace-registry-host = "npmjs"
save = true
save-bundle = false
save-dev = false
save-exact = false
save-optional = false
save-peer = false
save-prefix = "^"
save-prod = false
sbom-format = null
sbom-type = "library"
scope = ""
script-shell = null
searchexclude = ""
searchlimit = 20
searchopts = ""
searchstaleness = 900
shell = "sh"
shrinkwrap = true
sign-git-commit = false
sign-git-tag = false
strict-peer-deps = false
strict-ssl = true
tag = "latest"
tag-version-prefix = "v"
timing = false
umask = 0
unicode = false
update-notifier = true
usage = false
user-agent = "npm/{npm-version} node/{node-version} {platform} {arch} workspaces/{workspaces} {ci}"
userconfig = "/root/.npmrc"
version = false
versions = false
viewer = "man"
which = null
workspace = []
workspaces = null
workspaces-update = true
yes = null

; "env" config from environment

prefix = "/home/node/.npm-global"

; "cli" config from command line options

long = true

[jeremyVignelles]

Could reproduce locally (wsl debian and his repo, that I simplified here) and had the same error here:

FetchError: request to https://registry.npmjs.org/-/npm/v1/security/audits/quick failed, reason: write EPIPE

The issue doesn't seem to happen when docker is running in a VM (ubuntu) instead of WSL...

EDIT: passing --no-audit hides the error, but the install still freezes.

[jonesbusy]

Exact same issue here on Ubuntu 24.04 WSL2 and npm 10.9.0

[Vincere1st]

Hi @jonesbusy , do you run npm inside a docker container or directly inside wsl2 ? Because i haven't try in wsl2 directly.

[jonesbusy]

Directly on WSL. Simple npm i hang.

I never faced such issue with Node 18 or 20 on WSL2

I don't see anything particular on logs

404 silly placeDep ROOT @jridgewell/sourcemap-codec@1.5.0 OK for: magic-string@0.30.12 want: ^1.5.0

Some minutes after

405 silly reify moves {}
406 silly audit bulk request {

[jonesbusy]

EDIT: Well in fact didn't hang. Took 7 minutes

added 30 packages in 7m

4 packages are looking for funding
  run `npm fund` for details

483 silly audit bulk request failed undefined
484 verbose audit error FetchError: request to https://registry.npmjs.org/-/npm/v1/security/audits/quick failed, reason: write EPIPE
484 verbose audit error     at ClientRequest.<anonymous> (/home/vald/.nvm/versions/node/v22.10.0/lib/node_modules/npm/node_modules/minipass-fetch/lib/index.js:130:14)
484 verbose audit error     at ClientRequest.emit (node:events:518:28)
484 verbose audit error     at emitErrorEvent (node:_http_client:103:11)
484 verbose audit error     at TLSSocket.socketErrorListener (node:_http_client:506:5)
484 verbose audit error     at TLSSocket.emit (node:events:518:28)
484 verbose audit error     at emitErrorNT (node:internal/streams/destroy:170:8)
484 verbose audit error     at emitErrorCloseNT (node:internal/streams/destroy:129:3)
484 verbose audit error     at process.processTicksAndRejections (node:internal/process/task_queues:90:21) {
484 verbose audit error   code: 'EPIPE',
484 verbose audit error   errno: 'EPIPE',
484 verbose audit error   syscall: 'write',
484 verbose audit error   type: 'system'
.....

590 verbose os Linux 5.15.133.1-microsoft-standard-WSL2
591 verbose node v22.10.0
592 verbose npm  v10.9.0

Doing the same on node20 is almost instant

[milaninfy]

We have similer issue happening #7814 these might be related.
which is not specific to WSL but some users are experiencing this, however I am still trying to reproduce the issue concretely where it hangs every time, once we able to reproduce they we can hunt for root cause.

[melodyarcjason]

Confirming that I am encountering this same hang/freeze and general slowness after updating to npm 10.9.0.

Running WSL2 w/ Ubuntu 22.04.3 LTS
Node 20.18

Fairly small vite project - nothing crazy. Was really slow on things like 'audit' and 'audit fix' . Very slow (10 mins) to complete npm outdated. Gave up after 15 min waiting on npm update.

Downgraded to npm @10.8.0 - working good now.

[Trimack93]

Same issue here. NPM 10.8.3 it works fine, on 10.9.0 installation freezes for 5-7 minutes. From the logs it looks like the freeze happens just before step "reify moves" (see my output from installing gzipper inside mcr.microsoft.com/dotnet/sdk:8.0 image using Docker Desktop 4.35.0).
npm install gzipper log.txt

There are also other app-related npm packages installed in this image later on. For some reason, second command with much more packages doesn't trigger this freeze (maybe due to cached content from previous command). Locally on Windows everything works fine regardless of NPM version.

[jeremyVignelles]

Has anyone been able to reproduce the exact same issue (npm 10.9 stuck for a few minutes but 10.8 working fine) outside of the context of WSL2 ? Does it happen with any npm package (without vite for example) ?

EDIT: Does not get stuck with is-number. This seems package-specific in some way.
EDIT2: I simplified this down to npm install rollup. Trimack93 has an issue with gzipper, that I can confirm on my side. I thought it has to do with the native dependencies of rollup, but I don't see anything like that with gzipper.

[jeremyVignelles]

Here is an excerpt of the logs with --timing always enabled:

#8 2.632 npm timing idealTree:buildDeps Completed in 788ms
#8 2.634 npm timing idealTree:fixDepFlags Completed in 1ms
#8 59.73 npm timing idealTree Completed in 57903ms
#8 59.73 npm timing reify:loadTrees Completed in 57905ms
#8 59.74 npm timing reify:diffTrees Completed in 4ms
#8 59.74 npm silly reify moves {}
#8 59.74 npm timing reify:retireShallow Completed in 1ms
#8 59.76 npm timing reify:createSparse Completed in 25ms
#8 59.77 npm timing reify:loadBundles Completed in 0ms
#8 331.2 npm verbose reify failed optional dependency /app/node_modules/fsevents
#8 331.2 npm silly reify mark deleted [ '/app/node_modules/fsevents' ]
#8 331.2 npm verbose reify failed optional dependency /app/node_modules/@rollup/rollup-win32-x64-msvc
#8 331.2 npm silly reify mark deleted [ '/app/node_modules/@rollup/rollup-win32-x64-msvc' ]

There are two places where the process is stuck for a long time. In both places, I see the same call:

cli/workspaces/arborist/lib/arborist/build-ideal-tree.js

Line 212 in 977fd57

checkPlatform(node.package, this.options.force)

cli/workspaces/arborist/lib/arborist/reify.js

Line 712 in 977fd57

checkPlatform(node.package, false, { cpu, os, libc })

It's getting late here, but I suspect something wrong going on here, which could explain why this is platform-dependant.

[SamJbori]

I am running into a similar issue where npm 10.9.0 just freeze when running eas-cli local build command
eas build --platform android --local
I tried reinstalling npm, node, I even built a new WSL with 2 different versions and I get the same result always no matter what.

10.8.3 worked just fine.

[stacy-rendall]

Similar issue on WSL2 Ubuntu 22.04 and 24.04, NPM 10.9.0 - freeze is particularly prevalent on npm update, but sometimes seems to happen for npm install too...

Freeze is typically 2 hours for projects using an Azure DevOps artifacts registry, and ~50 minutes for projects using NPM registry.

Just noticed a possible workaround while trying to test: seems to work without freezing if timing=always is used - i.e. npm update --timing=always

[stheine]

Has anyone been able to reproduce the exact same issue (npm 10.9 stuck for a few minutes but 10.8 working fine) outside of the context of WSL2 ? Does it happen with any npm package (without vite for example) ?

I have the issue on a plain Ubuntu 24.04.1, node 22.11.0, npm 10.9.0, clearly reproducible.

$ npm --version 
10.9.0
$ rm -rf package-lock.json node_modules/
$ npm i
[...]
added 1716 packages, and audited 1717 packages in 3h

works fine with npm 10.8.3

$ npm i -g npm@10.8.3
$ npm --version 
10.8.3
$ rm -rf package-lock.json node_modules/
$ npm i
[...]
added 1716 packages, and audited 1717 packages in 4m

let me know if you want me to test something specific.

[stheine]

in #7814 someone mentioned pihole. I also have pihole running, and here is a snapshot of the activity when the 3hour npm install was running yesterday:

The light-green is the Ubuntu system running the npm install.

and this is a snipped of the detailed log:

[Tofandel]

This is a duplicate of #7814 and #4028, if you want to get around the bug you can possibly run npm install --force --libc=glibc which will skip both buggy code or downgrade to npm 10.3.0

[wraithgar]

This was fixed in npm 10.9.1 (via npm/npm-install-checks#120)