Skip to content

NPM 1.3.11 seems borked - npm install fails first time, 100% of the time #3940

sandfox opened this Issue Sep 26, 2013 · 23 comments

9 participants

sandfox commented Sep 26, 2013

When using either node 0.10.19 or 0.11.7 it is seemingly impossible to run npm install successfully first time with a large dependency list (49 first level dependencies) . At arbitrary points in the installation process errors like this are seen :

node 0.10.19
npm ERR! cb() never called!
npm ERR! not ok code 0
The command "npm install" failed. Retrying, 2 of 3.
node 0.11.7
npm ERR! Error: shasum check failed for /home/travis/tmp/npm-971-ZLjLyYv9/1378478406714-0.9797422615811229/tmp.tgz
npm ERR! Expected: acf472ac07defc6d090976be0e37aebb2e796911
npm ERR! Actual:   7e6740962c5ede06b9dca457b0f1408b6acd64c4
npm ERR!     at /home/travis/.nvm/v0.11.7/lib/node_modules/npm/node_modules/sha/index.js:38:8
npm ERR!     at ReadStream.<anonymous> (/home/travis/.nvm/v0.11.7/lib/node_modules/npm/node_modules/sha/index.js:85:7)
npm ERR!     at ReadStream.EventEmitter.emit (events.js:125:20)
npm ERR!     at _stream_readable.js:896:16
npm ERR!     at process._tickCallback (node.js:317:11)
npm ERR! If you need help, you may report this log at:
npm ERR!     <>
npm ERR! or email it to:
npm ERR!     <>
npm ERR! System Linux 2.6.32-042stab061.2
npm ERR! command "/home/travis/.nvm/v0.11.7/bin/node" "/home/travis/.nvm/v0.11.7/bin/npm" "install"
npm ERR! cwd /home/travis/build/Bizzby/bizzby
npm ERR! node -v v0.11.7
npm ERR! npm -v 1.3.8
npm ERR! 
npm ERR! Additional logging details can be found in:
npm ERR!     /home/travis/build/Bizzby/bizzby/npm-debug.log
npm ERR! not ok code 0
The command "npm install" failed. Retrying, 2 of 3.

These tests are all been run on travis which uses a fresh build environment every time.

I'm going to try and reference all the other tickets which seem to be related to the bug to make everyones lives easier (I hope) - Feel free to add any I have missed (there are probably many)





Same thing here. Cant install a single package on the remote machine.




For what it's worth, my Heroku is now completely unable to install from my package.json. Unsure what version they're running.

sandfox commented Sep 27, 2013

@andRyanMiller By the looks of it they are using node 0.10.19 with npm 1.2.30 which at first sight seems a non-standard combo considering even node 0.10.18 shipped with npm 1.3.8, but maybe it's taken from your 'package.json'? have you tried a build specifying npm 1.3.8?

luk- commented Sep 27, 2013

@sandfox Package.json was off - bumped to 1.3.8 yet error persists. Solution was to drop Node version to 0.10.17 for the time being.

sandfox commented Sep 27, 2013

@andRyanMiller did you try 0.10.18? If so did that fail for you too?


@andRyanMiller my solution was the same as yours, drop node down to 0.10.17 in order to get npm to install properly again. I should note, this issue only happens for me when the --production flag is set (like it is in Heroku)

I tried node v0.10.19 with npm 1.3.11, 1.3.8, and 1.2.30 and it fails in a consistent manner after getting ~20 packages.

This problem exists on Linux (via Heroku), on Windows XP (my environment), and OSX 10.8.5 although much more intermittently.

This was referenced Sep 29, 2013

As my other issue was closed, I hope it is OK that I continue here on this one.

I can see that downgrading has worked for some users here; not so for me. I have tried several versions from 1.10.10 and up, and all of them seem to generate the same error message. I am behind a corporate firewall and proxy, but I have never experienced this issue before. My Macintosh is on the same network, but does not have the same issues. Both the macintosh and the windows macine have npm configured with proxy and https-proxy settings, and strict-ssl set to false.

If you need me to run any tests, just shout.

luk- commented Oct 1, 2013

Please try the solution in #2907

@luk- luk- closed this Oct 1, 2013

This did not fix my issue. Would you like me to continue in this issue or my original one? (#3945)

@luk- luk- reopened this Oct 1, 2013
luk- commented Oct 1, 2013

Didn't mean to close this

sandfox commented Oct 1, 2013

@bendiksolheim could attach / post the output of npm install with the new version of node (0.10.20). At a total guess, I'm guessing the fix works well on linux, but maybe not so much for windows...


Ok, so I made new gists with the new logs:
Normal logging:
Silly logging:

One thing I noticed is that it tries to write to the AppData\Local\Temp. The setup on these machines is a bit special, as the user home-folder is actually mapped to a network drive. I know this has been causing problems when using Maven before. The weird thing is that when installing for example expressjs or grunt, I get no errors, so I don't really think it should matter.

JDWardle commented Oct 2, 2013

It seems that the latest version of NodeJS causes problems with npm. Going back to version 0.10.17 of NodeJS fixed the issue for me. Just had to fix this at work, no idea if any versions newer than 0.10.17 will work.

sandfox commented Oct 3, 2013

@sedushi - 0.10.20 should fix the problem (it was something TLS related in core).
What O/S are you on?

JDWardle commented Oct 4, 2013

@sandfox I am on Ubuntu 12.04. And I did end up trying it with 0.10.20 and it worked fine as well.


I belive I might have gotten a bit closer to the issue. I found that also fails on me, with the exact same error message as before. It also failed on zeparser, as is the case with karma. The latest version of zeparser (0.0.7) seems to install just fine, but and karma both installs version 0.0.5, and when I install that exact version with npm install zeparser@0.0.5 it fails with the same error message as with karma and

After som diggin around, the problem on is the following dependency chain: -> -> active-x-obfuscator@0.0.1 -> zeparser@0.0.5
And because is a dependancy of karma, this also affects karma.

I don't know if this is the correct place to ask, but does this indicate that there is an error in the package itself, or could it be a corrupt package in the npm repository? Or maybe some weird issue on my machine?

Is there a way for me to force use of zeparser@0.0.7 when installing karma and just cross my fingers that it will work, or do I need to wait until the developers update their dependency list?

npm member

@bendiksolheim does npm cache clean work for you before retrying it with the stable version of node?


npm cache clean does not change anything. I have attached logs of installing just zeparser@0.0.5 with the latest stable version:
Silly logging:

I noticed something interesting: the "Actual" shasum printed in those logs changes each time i run npm install zeparser@0.0.5. So I downloaded the file (which I got from npm info zeparser@0.0.5: tarball: '') directly with wget and computed the sha1sum with some windows utility, and this checksum is the same as the one I get from npm info zeparser@0.0.5. So it seems that when I download the file directly everything works OK, but not when I download it with npm. I also checked the file that is downloaded to the Temp folder (tmp.tgz). This file was only 1944 bytes, while the one I downloaded with wget is 2.1 MB. 7zip does not recognize tmp.tgz as a valid archive either.


I finally got hold of another windows laptop to do some more testing, and it might seem like it is the network here that messes things up. When using regular 3G on my phone, everything installed fine. I will contact the network department here and try to do some testing with them, so please just put this on hold so you won't waste any more time on it :)


Ok, this will be the last update from me :)

I have finally found the problem. It turned out to be a firewall issue that was giving us problems. The reason I did not expect it to be the firewall was that downloading the file with curl, wget or a browser worked fine. Even the checksum turned out to be correct then. However, for some reason it blocked the request when npm tried installing the package. I still have no clue as to why exactly it blocks this exact file from being accessed by npm, we simply fixed the issue by tunnelling traffic to through the firewall.

I hope this hasn't caused too much hassle for you, and I am sorry for any inconvenience. In retrospect I should have suspected the firewall much earlier. Thank you for the patience :) I consider the issue solved, so you may close the issue if you would like.

sandfox commented Oct 8, 2013

@bendiksolheim Awesome to know you've found the problem. Going to close this now as I'm pretty sure everyones problems are now fixed with the new node releases and firewall fixes

@sandfox sandfox closed this Oct 8, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.