cli
cli copied to clipboard
npm
[BUG] <Freezes during npm install>
Is there an existing issue for this?
- [X] I have searched the existing issues
This issue exists in the latest npm version
- [X] I am using the latest npm
Current Behavior
While running the command npm install with the latest version (V10.9.0), the installation pauses and does not proceed further.
To resolve this, I have attempted the following steps:
- Cleared the npm cache using npm cache clean --force.
- Restarted both my PC and Visual Studio Code.
- Deleted the package-lock.json file and the node_modules directory. But none of these worked.
Expected Behavior
Sould have installed the dependencies and created package-lock.json and node_modules.
Steps To Reproduce
Environment: Using Visual Studio Code with Node.js version 20.13.1. React and TypeScript: The project uses React version 18.2.0 and TypeScript version 5.3.3. Command: When I run npm install, the process appears to be loading continuously without any further progress.
Environment
- npm: 10.9.0
- Node.js: 20.13.1
- OS Name: Ubuntu 20.04.6 LTS
- npm config: `
This type of behaviour is not easy to track without reproduction steps or other details. It would be helpful for triaging this issue if you can provide details like package.json, package-lock, npm config, logs and command used.
Is it happening for all your project or a specific one ?
Same issue in my project. With npm 10.8.3 and below everything ok. My dockerfile:
FROM node:18.19-alpine as node
WORKDIR /home/node/frontend
RUN npm install -g npm@latest
RUN npm i -g @angular/[email protected]
RUN npm i -g @angular/[email protected] takes 90 minutes. Last few runs from 3 days:
90' 18".
90' 17",
90' 23",
90' 26".
FROM node:18.19-alpine as node
WORKDIR /home/node/frontend
RUN npm install -g [email protected]
RUN npm i -g @angular/[email protected]
RUN npm i -g @angular/[email protected] takes few seconds
Checked on 5 machines.
for some reason mine is not showing any delays... are you using npm registry or custom hosted registry settings ?
~/workarea/rep $ cat dockerfile
FROM node:18.19-alpine as node
WORKDIR /home/node/frontend
RUN npm install -g [email protected]
RUN npm i -g @angular/[email protected] --verbose
/workarea/rep $ docker build .
[+] Building 27.6s (8/8) FINISHED docker:desktop-linux
=> [internal] load build definition from Dockerfile 0.0s
=> => transferring dockerfile: 173B 0.0s
=> [internal] load metadata for docker.io/library/node:18.19-alpine 0.5s
=> [internal] load .dockerignore 0.0s
=> => transferring context: 2B 0.0s
=> [1/4] FROM docker.io/library/node:18.19-alpine@sha256:c7620fdecfefb96813da62519897808775230386f4c8482e972e37b8b18cb460 0.0s
=> CACHED [2/4] WORKDIR /home/node/frontend 0.0s
=> [3/4] RUN npm install -g [email protected] 3.2s
=> [4/4] RUN npm i -g @angular/[email protected] --verbose 23.5s
=> exporting to image 0.4s
=> => exporting layers 0.4s
=> => writing image sha256:4b808728df586e52ff67c1be40887acd0af1795376777f9f2123631b7df2f1d8
npm registry.
5 machines was in different locations in Poland with different ISP.
ok then that sounds like it mostly not be registry related.
if possible, will you be able to share install log files from this command run where it takes time RUN npm i -g @angular/[email protected] -ddd in your docker step ?
It seems problem is related to high dns pool rate. I have pi-hole as dns in my network. In pi-hole log I have information about rate limiting for my IP: "Client 192.168.8.113 has been rate-limited (current config allows up to 1000 queries in 60 seconds)". It happens only in one moment during install - before line reify moves {} appears in log.
I chagned my dns to google and cloudflare ommiting pi-hole. Result in the attachment. Today times are much shorter but still too long. Below logs.
docker_build_cloudflare_dns.log
docker_build_google_dns.log
docker_build_pihole_cloudflare.log
logs with [email protected] docker_build_npm_10_8_3.log
There is no reify moves {}
@mi-lchlebowski Do you think this is related to https://github.com/npm/cli/issues/4028?
I've seen something like this with npm 10.9.0 when run by docker build. Doesn't occur on the host machine. Doesn't occur with npm 10.8.3. Workaround was to pin npm to 10.8.
I'm having the same issue with 10.9.0 when building docker images.
@mi-lchlebowski Do you think this is related to #4028?
No. Issue is always in same place.
@riceyrice @dirkhekhuisascendtek please add -ddd to npm i and paste log. Maybe this will be reify move too?
IMO it may be related to dns queries. On docker there is no dns cache instead host machine.
We've been experiencing the same issue. NPM installs from a node:20-bookworm container (with both IPv4 and IPv6 connectivity, both working correctly) sometimes take several hours to complete. I've attached a log below (with silly debug logging) of an install that took upwards of 5 hours.
You can see that npm logs npm silly idealTree buildDeps at 5 seconds, and the next log line is at 20990 seconds (after 5.8 hours).
Another thing to note is this line, where it seems it took npmjs.org almost 30 minutes to reply to the advisories call.
npm http fetch POST 200 https://registry.npmjs.org/-/npm/v1/security/advisories/bulk 1778840ms
Same here. Only get the problems with our corporate VPN. Moving back to NPM 10.8.0 helps. Goging back to 10.9.0 breaks again. Also 10.9.0 works in our office network (without VPN). Also disabled auditing with audit=false, but the problems described above are still there.
I had the same issue when I upgraded NPM to v10.9: it freezes (the animations stops) after a while when running commands installing packages. I downgraded to v10.8.3 and no longer have this problem.
@riceyrice please add -ddd to
npm iand paste log. Maybe this will be reify move too?
Could be - it froze for around 25 minutes, with a reify moves output just after, or maybe that fetch GET has a very silly timeout!?
#15 [base base 10/14] RUN npm ci -ddd
#15 0.441 npm verbose cli /usr/bin/node /usr/bin/npm
#15 0.441 npm info using [email protected]
#15 0.441 npm info using [email protected]
#15 0.441 npm silly config load:file:/usr/lib/node_modules/npm/npmrc
#15 0.441 npm silly config load:file:/app/.npmrc
#15 0.441 npm silly config load:file:/root/.npmrc
#15 0.441 npm silly config load:file:/usr/etc/npmrc
#15 0.445 npm verbose title npm ci
#15 0.445 npm verbose argv "ci" "--loglevel" "silly"
#15 0.445 npm verbose logfile logs-max:10 dir:/root/.npm/_logs/2024-10-11T08_19_02_954Z-
#15 0.447 npm verbose logfile /root/.npm/_logs/2024-10-11T08_19_02_954Z-debug-0.log
#15 0.643 npm silly logfile done cleaning log files
#15 0.681 npm silly packumentCache heap:4345298944 maxSize:1086324736 maxEntrySize:543162368
#15 0.888 npm silly idealTree buildDeps
#15 1566.7 npm http fetch GET https://registry.npmjs.org/npm attempt 1 failed with ECONNRESET
#15 1566.7 npm silly reify moves {}
Aha, I was writing up network details in case this is some DNS thing: Docker 4.34.2 (167172) on Windows 11 with WSL2 backend, Tailscale VPN (disconnected). Connected the VPN and the delay is 5s instead:
#15 0.586 npm silly packumentCache heap:4345298944 maxSize:1086324736 maxEntrySize:543162368
#15 0.796 npm silly idealTree buildDeps
#15 5.310 npm silly reify moves {}
Since it's not reproducible/traced even based on logs, Please provide as much information as you can, this would help greatly. just like attached Logs ( Thanks for that ), Operating system information, versions of tech stack used, configs, package file etc.
I have the same issue and I already explained it in https://github.com/npm/cli/issues/4028#issuecomment-2388390371
Since I can reproduce it 100% of the time after npm 10.4.0, I could help providing a repro because I'm at loss on debugging this further (but because it happens only when there is a lot of dependencies it cannot really be a minimal repro, I can just copy paste my package.json from a project that has it)
Happened to me in WSL after upgrade to NodeJS 22.10.0, which comes with npm 10.9.0, while nvm installs packages listed in ~/.nvm/default-packages.
Example for package that causes npm to hang is pm2: npm i -g pm2
Downgrade to 10.8.3 helps.
Example for package that causes npm to hang is pm2:
npm i -g pm2
It's really random. I've just done npm i -g pm2 (with npm 10.9.0 / Node 22.10.0), and it worked.
I think that would be more likely to happen when installing a lot of packages (like npm i in a "big" project).
Strangely I had a moment today where it suddenly worked. Then I cleared the cache (npm cache clean --force) and the problem reappeared. Here are the last lines of '-ddd' output:
npm silly packumentCache full:https://registry.npmjs.org/git-sha1 set size:undefined disposed:false
npm http fetch GET 200 https://registry.npmjs.org/bodec 50ms (cache miss)
npm silly packumentCache full:https://registry.npmjs.org/bodec set size:undefined disposed:false
npm silly placeDep node_modules/pm2 [email protected] OK for: [email protected] want: ^0.1.0
npm silly placeDep node_modules/pm2 [email protected] OK for: [email protected] want: ^0.1.2
npm silly placeDep node_modules/pm2 [email protected] OK for: [email protected] want: ^0.1.2
npm silly placeDep node_modules/pm2 [email protected] OK for: [email protected] want: ^0.2.5
npm silly placeDep node_modules/pm2/node_modules/@pm2/agent [email protected] OK for: [email protected] want: ^6.0.0
npm silly fetch manifest yallist@^4.0.0
npm silly packumentCache full:https://registry.npmjs.org/yallist cache-miss
npm http fetch GET 200 https://registry.npmjs.org/yallist 47ms (cache miss)
npm silly packumentCache full:https://registry.npmjs.org/yallist set size:undefined disposed:false
npm silly placeDep node_modules/pm2 [email protected] OK for: [email protected] want: ^4.0.0
npm silly placeDep node_modules/pm2 [email protected] OK for: [email protected] want: ^4.17.14
npm silly placeDep node_modules/pm2/node_modules/@pm2/io [email protected] OK for: [email protected] want: ^6.0.0
Then it wait's for more than an hour. Now when I press Ctrl-C and try another time it works. Here's how the log continues, with some overlapping lines:
npm silly fetch manifest yallist@^4.0.0
npm silly packumentCache full:https://registry.npmjs.org/yallist cache-miss
npm http fetch GET 200 https://registry.npmjs.org/yallist 2ms (cache hit)
npm silly packumentCache full:https://registry.npmjs.org/yallist set size:34610 disposed:false
npm silly placeDep node_modules/pm2 [email protected] OK for: [email protected] want: ^4.0.0
npm silly placeDep node_modules/pm2 [email protected] OK for: [email protected] want: ^4.17.14
npm silly placeDep node_modules/pm2/node_modules/@pm2/io [email protected] OK for: [email protected] want: ^6.0.0
npm silly reify mark retired [
npm silly reify '/home/user/.nvm/versions/node/v22.10.0/lib/node_modules/pm2',
npm silly reify '/home/user/.nvm/versions/node/v22.10.0/bin/pm2',
npm silly reify '/home/user/.nvm/versions/node/v22.10.0/bin/pm2-dev',
npm silly reify '/home/user/.nvm/versions/node/v22.10.0/bin/pm2-docker',
npm silly reify '/home/user/.nvm/versions/node/v22.10.0/bin/pm2-runtime'
npm silly reify ]
npm silly reify moves {
npm silly reify '/home/user/.nvm/versions/node/v22.10.0/lib/node_modules/pm2': '/home/user/.nvm/versions/node/v22.10.0/lib/node_modules/.pm2-170ltMvY',
It might be interesting, that in the second part there's a size of yallist, which is undefined in the first part:
npm silly packumentCache full:https://registry.npmjs.org/yallist set size:34610 disposed:false
Hey, I have also noticed this bug in one of my solutions, but it seems to struggle only with older packages, as projects with up to date stuff don't seem to be affected. In my windows workstation environment in cmd everything installs and builds fine, but in docker build on the same computer, the older solutions hangs, it takes 45 minutes for npm i step, but it goes thru and doesn't crash, so I assume there is some spaghetti involved.
To people struggling with this bug in docker, an easy temporary fix is to change in the dockerfile
FROM node:latest AS node
to
FROM node:18 AS node
And then it seems to install and build as before.
I can confirm a flood of DNS requests (15.000 and more) within a few seconds originating from my system when I run npm update --save.
The requests are all PTR requests, e.g. 100.0.168.192.in-addr.arpa, where my local IP is 192.168.0.100.
Depending on the local setup these requests might be sent to a provider DNS or at least the local router and could severely affect network performance. In any case they could explain rate-limiting, freezes and other obscure issues.
npm 10.9.0
node 20.17.0
@aleho I can confirm the same behavior with a flood of PTR DNS requests to 35.1.16.104.in-addr.arpa.
Edit: The problem with these DNS queries no longer occurs after a downgrade to NPM v10.8.3. Then, only a few of those PTR DNS requests will be sent.
Could this have been caused by this change https://github.com/npm/cli/commit/6ca609e20b68fb2e5ef8177db116b84a339461fd or is ping not used during npm install?
I tried npm v10.8.3 but I still get a freeze, so the freeze for me is not caused by the DNS queries, if I downgrade version by version it starts working at 10.3.0, I'd like to add that while it's hanging, cpu is at 0% but the timer of the command stops increasing in htop
Any idea on what I can use to debug this further? I tried the V8 profiler in a setTimeout but apparently it's not just waiting, it's actually completely frozen and the setTimeout doesn't fire once the hang occurs
What could cause such a hang where it's the actual node process that froze?
@Tofandel If you are consistently reproduce the issue at your end and if you want to debug it further at code level, you can setup npm-cli codebase locally and give it a try with switching to various commits from change-log.
Yes and I found the issue and opened a PR with a fix https://github.com/npm/cli/issues/4028#issuecomment-2441942581 https://github.com/npm/npm-install-checks/pull/120/files
seeing a 25 minute freeze, doesn't respond to SIGTERM as well, only SIGKILL. reify moves {} step isn't the one that is freezing for me
node: v22.11.0 npm: v10.8.3
2206 timing idealTree:buildDeps Completed in 43683ms
2207 timing idealTree:fixDepFlags Completed in 3ms
2208 timing idealTree Completed in 43729ms
2209 timing reify:loadTrees Completed in 43730ms
2210 timing reify:diffTrees Completed in 3ms
2211 silly reify moves {}
2212 timing reify:retireShallow Completed in 1ms
2213 timing reify:createSparse Completed in 325ms
2214 timing reify:loadBundles Completed in 0ms
[...]
2357 timing reifyNode:node_modules/fsevents Completed in 1504245ms
2358 timing reifyNode:node_modules/@parcel/watcher-win32-x64 Completed in 1504245ms
2359 timing reifyNode:node_modules/@parcel/watcher-win32-ia32 Completed in 1504246ms
2360 timing reifyNode:node_modules/@parcel/watcher-win32-arm64 Completed in 1504246ms
2361 timing reifyNode:node_modules/@parcel/watcher-linux-x64-musl Completed in 1504246ms
2362 timing reifyNode:node_modules/@parcel/watcher-linux-arm64-musl Completed in 1504246ms
2363 timing reifyNode:node_modules/@parcel/watcher-linux-arm64-glibc Completed in 1504246ms
2364 timing reifyNode:node_modules/@parcel/watcher-linux-arm-glibc Completed in 1504246ms
2365 timing reifyNode:node_modules/@parcel/watcher-freebsd-x64 Completed in 1504247ms
2366 timing reifyNode:node_modules/@parcel/watcher-darwin-x64 Completed in 1504247ms
2367 timing reifyNode:node_modules/@parcel/watcher-darwin-arm64 Completed in 1504247ms
2368 timing reifyNode:node_modules/@parcel/watcher-android-arm64 Completed in 1504247ms
2369 silly audit bulk request failed undefined
2370 verbose audit error FetchError: request to https://registry.npmjs.org/-/npm/v1/security/audits/quick failed, reason: write EPIPE
2370 verbose audit error at ClientRequest.<anonymous> (/usr/lib/node_modules/npm/node_modules/minipass-fetch/lib/index.js:130:14)
2370 verbose audit error at ClientRequest.emit (node:events:518:28)
2370 verbose audit error at emitErrorEvent (node:_http_client:103:11)
2370 verbose audit error at Socket.socketErrorListener (node:_http_client:506:5)
2370 verbose audit error at Socket.emit (node:events:518:28)
2370 verbose audit error at emitErrorNT (node:internal/streams/destroy:170:8)
2370 verbose audit error at emitErrorCloseNT (node:internal/streams/destroy:129:3)
2370 verbose audit error at process.processTicksAndRejections (node:internal/process/task_queues:90:21) {
2370 verbose audit error code: 'EPIPE',
2370 verbose audit error errno: 'EPIPE',
2370 verbose audit error syscall: 'write',
2370 verbose audit error type: 'system'
2370 verbose audit error }
2371 silly audit error undefined
2372 timing auditReport:getReport Completed in 1504316ms
2373 silly audit report null
2374 timing reify:audit Completed in 1504317ms
As I've already explained this issue has been located already and a PR is open in both node to fix the root of the issue and npm to implement a workaround
There is no need to paste more logs that don't add any significant information to the issue but noise, thank you
The issue will be fixed when either one of https://github.com/nodejs/node/pull/55602 or https://github.com/npm/npm-install-checks/pull/120 lands
In the meantime you can use --force --libc=glibc or downgrade to npm 10.3.0 to avoid this issue