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
SLOW OR FAILED (500 ERROR) NODE.JS DOWNLOADS #4495
Browser version: Firefox 98.0.0, Firefox Nightly 100.0a1 (2022-03-15), curl 7.47.0 (Travis CI), curl 7.68.0 (my local machine) (Doesn't feel like a browser issue, feels like a server issue...)
Operating system: Ubuntu 20.04 / Linux Mint 20
When trying to get files off of nodejs.org/dist/... or nodejs.org/download/..., I get a server error.
"500 Internal Server Error"
(error page served by nginx)
Full error message page (HTML snippet, click to expand)
<html><head><title>500 Internal Server Error</title></head><bodybgcolor="white"><center><h1>500 Internal Server Error</h1></center><hr><center>nginx</center></body></html>
Given that the outage seems sporadic: Maybe it's a resource exhaustion issue over at the server? Running out of RAM or something?? I don't know.
Edit to add: The error message page seems to be served by Cloudflare. (According to the server: cloudflare response header, when looking in browser dev tools). So I guess this is a Cloudflare issue? Actually that's probably not what that means.
It's the latest LTS release, so everybody in the world looking for the default version of Node is downloading uncached right now, basically. (Other than as apparently cached by Cloudflare).
Should settle down in a few hours, or by tomorrow??
Note: I have nothing to do with Node's web servers or site, I'm just a regular person speculating at this point.
I have CloudFlare LB error notices spanning from ~2:40 am UTC to ~3:40 am UTC, which I suppose correlates with the latest 16.x release. Overloaded primary server, switching to the backup. Users may have got the 500 while hitting the primary before it switched.
I don't have a good explanation beyond that, I'm not sure what's caused the overload, I don't believe that server actually has trouble serving, but we have witnessed some weird I/O issues connected with rsync that maybe all happened at the same time. Perhaps during the next release someone should be on the server watching for weirdness.
FWIW I am still seeing either "500 internal server error" or very slow file downloads (less than 50 kilobytes a second. Often less than 10 kilobytes a second, especially at the beginning of a download.)
More details (click to expand):
The "slow download" symptom is less obvious for small files, because they complete quickly anyway.
I have seen a tarball download start, take a long time (over a minute), and ultimately fail to download mid-way through.
I hope that's useful to diagnose the problem. (Results may vary across the globe, since the path through the CDN is probably not identical everywhere?)
Edit to add: My experience is basically identical (as described in this comment) for nodejs.org/dist/ and iojs.org/dist. And identical experience today compared to 2 days ago.
After promoting 12.22.11 I went to rerun the same release script to promote 14.19.1 and it just hung during the bit when it fetches the promotable builds. Same behaviour from another machine on a different network. Weirdly I was able to ssh into the machine in an interactive session and manually run the command the promotion script was trying to run 😕.
I don't have a good explanation beyond that, I'm not sure what's caused the overload, I don't believe that server actually has trouble serving, but we have witnessed some weird I/O issues connected with rsync that maybe all happened at the same time. Perhaps during the next release someone should be on the server watching for weirdness.
I logged into the machine, ran ps -ef and saw we had two rsyncs in progress
The first of those, running as root, is from the backup server -- I've left that alone. I killed the second one, which is the coverage data, and suddenly my other terminal running the promotion script got unstuck. This would kind of suggest the coverage data syncing is partly, or wholly, responsible. In the past either @mhdawson or I would do an annoying manual clear up of old coverage data to reduce the volume of stuff being synced but I'm going to recommend now we turn off running coverage on Jenkins and the associated data shuffling to populate coverage.nodejs.org and switch exclusively to codecov.io.
Actually as I typed the above paragraph my promotion execution has broken 😢 so there's still something up with the machine:
Are you sure you want to promote the v14.19.1 assets? [y/n] y
client_loop: send disconnect: Broken pipe
Happening same here. Know this type of comments are not useful in most cases, but in this case at least serves to know that there are users still being affected 😬
Downloading: https://nodejs.org/dist/v18.17.1/node-v18.17.1-linux-x64.tar.gz
##[error]Aborted
##[warning]Content-Length (44417128 bytes) did not match downloaded file size (8204861 bytes).
we were facing this as well for quite some time. only solution to mitigate this is to use cached nodejs that ships with container :-/ not the best thing in the world, but it is what it is microsoft/fluentui#29552
Activity
SheetJSDev commentedon Mar 16, 2022
For some reason, iojs.org redirected to nodejs.org, causing errors with
nvm(https://github.com/SheetJS/sheetjs/runs/5564331772 test failed when trying to fetch https://iojs.org/dist/v3.3.1/iojs-v3.3.1-linux-x64.tar.xz)DeeDeeG commentedon Mar 16, 2022
I wonder if the site/Cloudflare are just getting overwhelmed with traffic for people downloading the latest release?
Node v16.14.1 was released about an hour ago... #4494 / https://github.com/nodejs/node/releases/tag/v16.14.1
It's the latest LTS release, so everybody in the world looking for the default version of Node is downloading uncached right now, basically. (Other than as apparently cached by Cloudflare).
Should settle down in a few hours, or by tomorrow??
Note: I have nothing to do with Node's web servers or site, I'm just a regular person speculating at this point.
DeeDeeG commentedon Mar 16, 2022
Trott commentedon Mar 16, 2022
Closing as the issue isn't happening right now, but also pinging @nodejs/build in case there's anything to add here or something to be aware of.
Trott commentedon Mar 16, 2022
People are still reporting this over in the OpenJS Slack, so I'm going to re-open this until that gets sorted.
rvagg commentedon Mar 16, 2022
I have CloudFlare LB error notices spanning from ~2:40 am UTC to ~3:40 am UTC, which I suppose correlates with the latest 16.x release. Overloaded primary server, switching to the backup. Users may have got the 500 while hitting the primary before it switched.
I don't have a good explanation beyond that, I'm not sure what's caused the overload, I don't believe that server actually has trouble serving, but we have witnessed some weird I/O issues connected with rsync that maybe all happened at the same time. Perhaps during the next release someone should be on the server watching for weirdness.
ljharb commentedon Mar 17, 2022
This seems to be happening again; https://iojs.org/dist/index.json is 500ing, and v12.22.11 just went out.
(after about 5-10 minutes, the 500s seemed to stop, but it's still worth looking into)
DeeDeeG commentedon Mar 18, 2022
FWIW I am still seeing either "500 internal server error" or very slow file downloads (less than 50 kilobytes a second. Often less than 10 kilobytes a second, especially at the beginning of a download.)
More details (click to expand):
The "slow download" symptom is less obvious for small files, because they complete quickly anyway.
I have seen a tarball download start, take a long time (over a minute), and ultimately fail to download mid-way through.
I hope that's useful to diagnose the problem. (Results may vary across the globe, since the path through the CDN is probably not identical everywhere?)
Edit to add: My experience is basically identical (as described in this comment) for nodejs.org/dist/ and iojs.org/dist. And identical experience today compared to 2 days ago.
richardlau commentedon Mar 18, 2022
After promoting 12.22.11 I went to rerun the same release script to promote 14.19.1 and it just hung during the bit when it fetches the promotable builds. Same behaviour from another machine on a different network. Weirdly I was able to ssh into the machine in an interactive session and manually run the command the promotion script was trying to run 😕.
I logged into the machine, ran
ps -efand saw we had two rsyncs in progressThe first of those, running as root, is from the backup server -- I've left that alone. I killed the second one, which is the coverage data, and suddenly my other terminal running the promotion script got unstuck. This would kind of suggest the coverage data syncing is partly, or wholly, responsible. In the past either @mhdawson or I would do an annoying manual clear up of old coverage data to reduce the volume of stuff being synced but I'm going to recommend now we turn off running coverage on Jenkins and the associated data shuffling to populate coverage.nodejs.org and switch exclusively to codecov.io.
Actually as I typed the above paragraph my promotion execution has broken 😢 so there's still something up with the machine:
richardlau commentedon Mar 18, 2022
Currently there are no rsync processes -- but running the promotion script is "hung" again for me 😞.
These are the top things via
top:richardlau commentedon Mar 18, 2022
I think I'm going to bounce nginx.
KevLehman commentedon Mar 18, 2022
Happening same here. Know this type of comments are not useful in most cases, but in this case at least serves to know that there are users still being affected 😬
Edit: worked now for me
richardlau commentedon Mar 18, 2022
I did
systemctl restart nginx. I'm still seeing rsync processes from the backup server still running.44 remaining items
broksonic21 commentedon Sep 20, 2023
I actually just filed a parallel ticket for that one @pughpugh before I saw this: #5818 . Not sure why Cloudflare is caching 500s
joaomoreno commentedon Oct 10, 2023
Seen on an Azure DevOps agent:
shailendra043 commentedon Oct 17, 2023
gyp ERR! stack Error: 500 status code downloading checksum
pbering commentedon Oct 18, 2023
Please reopen as it still happens multiple times a day!
jeremills commentedon Oct 18, 2023
Same, still happening
Hotell commentedon Oct 18, 2023
we were facing this as well for quite some time. only solution to mitigate this is to use cached nodejs that ships with container :-/ not the best thing in the world, but it is what it is microsoft/fluentui#29552
jfuinsure commentedon Oct 18, 2023
Have been facing this intermittently too:
Downloading: https://nodejs.org/dist/v16.16.0/node-v16.16.0-win-x64.7z
##[error]Aborted
##[warning]Content-Length (17121358 bytes) did not match downloaded file size (5534315 bytes).
jfuinsure commentedon Oct 19, 2023
and happening again :(
Downloading: https://nodejs.org/dist/v16.16.0/node-v16.16.0-darwin-x64.tar.gz
##[error]Aborted
##[warning]Content-Length (30597385 bytes) did not match downloaded file size (5075560 bytes).
broksonic21 commentedon Oct 24, 2023
This was happening continually today at https://nodejs.org/dist/v20.8.1/node-v20.8.1-darwin-arm64.tar.gz
Any update on why this is closed?
ovflowd commentedon Oct 24, 2023
This is closed because it's a known issue, and we're working on it.
iansedano commentedon Oct 26, 2023
I've been getting this on GitHub Actions (
ubuntu-latest) for the last couple days:horttanainen commentedon Oct 31, 2023
@ovflowd
I think it would better communicate your intent if you closed this issue after you have solved it.
revert back to official nodejs mirror
revert back to official nodejs mirror (#265692)