This repository has been archived by the owner. It is now read-only.

npm shrinkwrap install - npm ERR! cb() never called! (Linux / OS X) #5920

Closed
vladikoff opened this Issue Aug 12, 2014 · 23 comments

Comments

Projects
None yet
@vladikoff

vladikoff commented Aug 12, 2014

Repo to reproduce: https://github.com/vladikoff/imagemin-wrap

Installation works fine at first, so I run npm shrinkwrap to shrinkwrap the modules.
After that I remove the node_modules directory and try to install the project again.
I get this error:

npm WARN package.json imagemin-wrap@1.0.0 No description
npm WARN package.json imagemin-wrap@1.0.0 No repository field.
npm WARN package.json imagemin-wrap@1.0.0 No README data
npm WARN package.json github-url-from-git@1.1.1 No repository field.
-
> gifsicle@0.1.7 postinstall /Users/vfilippov/tmp/imagemin-wrap/node_modules/grunt-contrib-imagemin/node_modules/imagemin/node_modules/imagemin-gifsicle/node_modules/gifsicle
> node index.js


> jpegtran-bin@0.2.8 postinstall /Users/vfilippov/tmp/imagemin-wrap/node_modules/grunt-contrib-imagemin/node_modules/imagemin/node_modules/imagemin-jpegtran/node_modules/jpegtran-bin
> node index.js

-
> optipng-bin@0.3.11 postinstall /Users/vfilippov/tmp/imagemin-wrap/node_modules/grunt-contrib-imagemin/node_modules/imagemin/node_modules/imagemin-optipng/node_modules/optipng-bin
> node index.js

✔︎ pre-build test passed successfully!
npm ERR! cb() never called!
npm ERR! not ok code 0
~/tmp/imagemin-wrap on master*
$ 

@sford

This comment has been minimized.

Show comment
Hide comment
@sford

sford Aug 18, 2014

Hey @vladikoff , thanks for merging my grunt-contrib-less PR the other day :-)

I am running into this same npm ERR! cb() never called! error when using shrinkwrap files... unfortunately I don't have a fix :-(

sford commented Aug 18, 2014

Hey @vladikoff , thanks for merging my grunt-contrib-less PR the other day :-)

I am running into this same npm ERR! cb() never called! error when using shrinkwrap files... unfortunately I don't have a fix :-(

@vladikoff

This comment has been minimized.

Show comment
Hide comment
@vladikoff

vladikoff Aug 20, 2014

Workaround is to go back to npm 1.3, i.e npm install -g npm@1.3

vladikoff commented Aug 20, 2014

Workaround is to go back to npm 1.3, i.e npm install -g npm@1.3

@jamiemccrindle

This comment has been minimized.

Show comment
Hide comment

jamiemccrindle commented Sep 17, 2014

+1

@othiym23

This comment has been minimized.

Show comment
Hide comment
@othiym23

othiym23 Sep 17, 2014

Contributor

Summary of what I've learned so far:

I've made a simpler package.json that will fail every time when run with the following:

time (rm -rf npm-shrinkwrap.json node_modules && \
      npm install --no-spin && \
      npm shrinkwrap --no-spin && \
      rm -r node_modules && \
      npm install --no-spin || \
      echo 'https://www.youtube.com/watch?v=iJMZDBEL8Tg')

In order to reliably exercise the race condition (which is what I think the problem is), there need to be at least 3 dependencies with lifecycle scripts (probably postinstall scripts, although I still haven't verified that), a fair number of decent-sized dependencies to install, and an npm-shrinkwrap.json file created with a relatively recent version of npm. At least one of the postinstall scripts will run to completion, and I've verified that there never any postinstall scripts running or queued up to run at the time npm (prematurely) exits.

  • I have established to my satisfaction that the problem is not with the lifecycle itself. That narrows it down to something having to do with how shrinkwrapped dependencies (which are installed directly from downloaded tarballs – their metadata is realized in npm-shrinkwrap.json, so no metadata is fetched from the registry) are handed off to either the install or the build algorithms.
  • I still have not figured out where the missing callback is, but I do know that the top-level install and installManyTop functions are never getting their callbacks called.
  • I suspect, but have not established, that there's something hinky going on inside the chain of calls that perform the writing of the package of the disk and then hand off execution to the lifecycle or the install and postinstall scripts.

@isaacs and I are both looking at this, and I would very much like to get it fixed in time for the release of npm@2.0.1 tomorrow. I make no promises, though, because this is turning out to be fantastically convoluted to debug.

Contributor

othiym23 commented Sep 17, 2014

Summary of what I've learned so far:

I've made a simpler package.json that will fail every time when run with the following:

time (rm -rf npm-shrinkwrap.json node_modules && \
      npm install --no-spin && \
      npm shrinkwrap --no-spin && \
      rm -r node_modules && \
      npm install --no-spin || \
      echo 'https://www.youtube.com/watch?v=iJMZDBEL8Tg')

In order to reliably exercise the race condition (which is what I think the problem is), there need to be at least 3 dependencies with lifecycle scripts (probably postinstall scripts, although I still haven't verified that), a fair number of decent-sized dependencies to install, and an npm-shrinkwrap.json file created with a relatively recent version of npm. At least one of the postinstall scripts will run to completion, and I've verified that there never any postinstall scripts running or queued up to run at the time npm (prematurely) exits.

  • I have established to my satisfaction that the problem is not with the lifecycle itself. That narrows it down to something having to do with how shrinkwrapped dependencies (which are installed directly from downloaded tarballs – their metadata is realized in npm-shrinkwrap.json, so no metadata is fetched from the registry) are handed off to either the install or the build algorithms.
  • I still have not figured out where the missing callback is, but I do know that the top-level install and installManyTop functions are never getting their callbacks called.
  • I suspect, but have not established, that there's something hinky going on inside the chain of calls that perform the writing of the package of the disk and then hand off execution to the lifecycle or the install and postinstall scripts.

@isaacs and I are both looking at this, and I would very much like to get it fixed in time for the release of npm@2.0.1 tomorrow. I make no promises, though, because this is turning out to be fantastically convoluted to debug.

@STRML

This comment has been minimized.

Show comment
Hide comment
@STRML

STRML Sep 17, 2014

Contributor

Thanks for looking into this, I am having the same issue since I switched to shrinkwraps. Definitely feels like a race condition, I get it in about 25% of builds.

Contributor

STRML commented Sep 17, 2014

Thanks for looking into this, I am having the same issue since I switched to shrinkwraps. Definitely feels like a race condition, I get it in about 25% of builds.

@othiym23 othiym23 referenced this issue Sep 18, 2014

Closed

wip #6215

@manuelmazzuola

This comment has been minimized.

Show comment
Hide comment
@manuelmazzuola

manuelmazzuola commented Sep 18, 2014

@STRML The same

@othiym23 othiym23 assigned isaacs and unassigned othiym23 Sep 19, 2014

@othiym23

This comment has been minimized.

Show comment
Hide comment
@othiym23

othiym23 Sep 19, 2014

Contributor

A quick update: this is proving to be a heroic pain in the ass to figure out, and @isaacs has so far written two new modules just to help him debug this one issue. He has suspected, variously, lib/build.js, node-tar, and graceful-fs, and we have found several "fixes" the are really only making the issue comparatively more rare. We had wanted to put the fix for this into npm@2.0.1, but it's proving to be too wily for that. Thanks for your continued patience!

Contributor

othiym23 commented Sep 19, 2014

A quick update: this is proving to be a heroic pain in the ass to figure out, and @isaacs has so far written two new modules just to help him debug this one issue. He has suspected, variously, lib/build.js, node-tar, and graceful-fs, and we have found several "fixes" the are really only making the issue comparatively more rare. We had wanted to put the fix for this into npm@2.0.1, but it's proving to be too wily for that. Thanks for your continued patience!

@isaacs

This comment has been minimized.

Show comment
Hide comment
@isaacs

isaacs Sep 19, 2014

Member

Holy nuts, this was a doozy.

Comes down to a race condition on this write file: https://github.com/npm/npm/blob/master/lib/cache/add-local-tarball.js#L206-L208

Replacing all our write streams with atomic write streams, and we should have a 2.0.2 out with the fix pretty soon.

Member

isaacs commented Sep 19, 2014

Holy nuts, this was a doozy.

Comes down to a race condition on this write file: https://github.com/npm/npm/blob/master/lib/cache/add-local-tarball.js#L206-L208

Replacing all our write streams with atomic write streams, and we should have a 2.0.2 out with the fix pretty soon.

@othiym23

This comment has been minimized.

Show comment
Hide comment
@othiym23

othiym23 Sep 20, 2014

Contributor

This is fixed in npm@2.0.2. Install it and confirm that it fixes your problem. The bards will sing of @isaacs's deeds on this day. This is the most ludicrously convoluted race condition (with, of course, a dead simple fix) that I've encountered in at least six months. Thanks everyone for your help running this one down!

Contributor

othiym23 commented Sep 20, 2014

This is fixed in npm@2.0.2. Install it and confirm that it fixes your problem. The bards will sing of @isaacs's deeds on this day. This is the most ludicrously convoluted race condition (with, of course, a dead simple fix) that I've encountered in at least six months. Thanks everyone for your help running this one down!

@vladikoff

This comment has been minimized.

Show comment
Hide comment
@vladikoff

vladikoff Sep 20, 2014

Great work guys, appreciate it. I'm really excited for npm 2, thanks for moving the platform forward. 🌟

vladikoff commented Sep 20, 2014

Great work guys, appreciate it. I'm really excited for npm 2, thanks for moving the platform forward. 🌟

@STRML

This comment has been minimized.

Show comment
Hide comment
@STRML

STRML Sep 20, 2014

Contributor

Great job! This one was killing my deploys, I really appreciate the quick response.

Contributor

STRML commented Sep 20, 2014

Great job! This one was killing my deploys, I really appreciate the quick response.

@backflip

This comment has been minimized.

Show comment
Hide comment
@backflip

backflip Sep 20, 2014

Thanks a lot!

backflip commented Sep 20, 2014

Thanks a lot!

@Carzeh

This comment has been minimized.

Show comment
Hide comment
@Carzeh

Carzeh Sep 21, 2014

Works for me! Thanks for the fix, was a nightmare troubleshooting this one...

Carzeh commented Sep 21, 2014

Works for me! Thanks for the fix, was a nightmare troubleshooting this one...

@othiym23

This comment has been minimized.

Show comment
Hide comment
@othiym23

othiym23 Sep 21, 2014

Contributor

@Carzeh ha ha ha you have no idea 😭

Contributor

othiym23 commented Sep 21, 2014

@Carzeh ha ha ha you have no idea 😭

@StoneCypher

This comment has been minimized.

Show comment
Hide comment
@StoneCypher

StoneCypher Oct 8, 2014

For people who come here to try to figure out what's wrong, it's worth noting that a corrupt NPM cache can trigger the same error for different reasons.

https://developer.appcelerator.com/question/157687

StoneCypher commented Oct 8, 2014

For people who come here to try to figure out what's wrong, it's worth noting that a corrupt NPM cache can trigger the same error for different reasons.

https://developer.appcelerator.com/question/157687

@othiym23

This comment has been minimized.

Show comment
Hide comment
@othiym23

othiym23 Oct 10, 2014

Contributor

As the followup to that question shows, something else was going on in that case.

cb() never called! is a catchall error, and can be triggered in a variety of circumstances (all of them ultimately down to bugs in npm). This particular instance was a consequence of a race condition in the npm cache, combined with a some unsanitary (non-atomic) file writes. As of npm@2.1.3, we've fixed a whole bunch of those issues and are currently unaware of anything that could trigger this error (which is not the same as saying we've completely eliminated all the potential causes of the error).

Contributor

othiym23 commented Oct 10, 2014

As the followup to that question shows, something else was going on in that case.

cb() never called! is a catchall error, and can be triggered in a variety of circumstances (all of them ultimately down to bugs in npm). This particular instance was a consequence of a race condition in the npm cache, combined with a some unsanitary (non-atomic) file writes. As of npm@2.1.3, we've fixed a whole bunch of those issues and are currently unaware of anything that could trigger this error (which is not the same as saying we've completely eliminated all the potential causes of the error).

@zddhub

This comment has been minimized.

Show comment
Hide comment
@zddhub

zddhub Jan 8, 2015

I meet the same question when install sequelize.
npm ERR! cb() never called!

zddhub commented Jan 8, 2015

I meet the same question when install sequelize.
npm ERR! cb() never called!

@Alex0007

This comment has been minimized.

Show comment
Hide comment
@Alex0007

Alex0007 Jan 9, 2015

+1

npm version 2.1.17

Alex0007 commented Jan 9, 2015

+1

npm version 2.1.17

@rich66

This comment has been minimized.

Show comment
Hide comment
@rich66

rich66 Jan 9, 2015

me as well
I can't update anything

rich66 commented Jan 9, 2015

me as well
I can't update anything

@krokofant

This comment has been minimized.

Show comment
Hide comment
@krokofant

krokofant Jan 16, 2015

Cannot update packages. Producing error npm ERR! cb() never called!

npm 2.1.16
node 0.10.31

krokofant commented Jan 16, 2015

Cannot update packages. Producing error npm ERR! cb() never called!

npm 2.1.16
node 0.10.31

@bmwertman

This comment has been minimized.

Show comment
Hide comment
@bmwertman

bmwertman Jan 18, 2015

Just installed the latest version of node(0.10.35) using the installer. This is suppose to install the latest version of npm, correct? Runnning npm -v still says I'm on npm version 1.4.28. I've also tried to use other suggested methods of installing npm(curl and build scripts).

install.sh | sh/synchro:curl -L https://npmjs.org/ 
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-  0     0    0     0    0     0      0      0 --:--:-- --:--:-100   193  100   193    0     0    392      0 --:--:-- --:--:-- --:--:--   392
100  6239  100  6239    0     0   9806      0 --:--:-- --:--:-- --:--:--  9806
tar=/usr/bin/tar
version:
bsdtar 2.8.3 - libarchive 2.8.3
install npm@latest
fetching: http://registry.npmjs.org/npm/-/npm-2.2.0.tgz

> npm@2.2.0 prepublish /private/var/folders/m0/vbmsjb1x1hd19f29z9794xj00000gn/T/npm.1227/package
> node bin/npm-cli.js prune --prefix=. --no-global && rm -rf test/*/*/node_modules && make -j8 doc

make: Nothing to be done for `doc'.
/Users/Brad/.node/bin/npm -> /Users/Brad/.node/lib/node_modules/npm/bin/npm-cli.js
npm@2.2.0 /Users/Brad/.node/lib/node_modules/npm
It worked   

Why does the above show npm@2.20 yet npm -v from the command line returns 1.4.28"

bmwertman commented Jan 18, 2015

Just installed the latest version of node(0.10.35) using the installer. This is suppose to install the latest version of npm, correct? Runnning npm -v still says I'm on npm version 1.4.28. I've also tried to use other suggested methods of installing npm(curl and build scripts).

install.sh | sh/synchro:curl -L https://npmjs.org/ 
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-  0     0    0     0    0     0      0      0 --:--:-- --:--:-100   193  100   193    0     0    392      0 --:--:-- --:--:-- --:--:--   392
100  6239  100  6239    0     0   9806      0 --:--:-- --:--:-- --:--:--  9806
tar=/usr/bin/tar
version:
bsdtar 2.8.3 - libarchive 2.8.3
install npm@latest
fetching: http://registry.npmjs.org/npm/-/npm-2.2.0.tgz

> npm@2.2.0 prepublish /private/var/folders/m0/vbmsjb1x1hd19f29z9794xj00000gn/T/npm.1227/package
> node bin/npm-cli.js prune --prefix=. --no-global && rm -rf test/*/*/node_modules && make -j8 doc

make: Nothing to be done for `doc'.
/Users/Brad/.node/bin/npm -> /Users/Brad/.node/lib/node_modules/npm/bin/npm-cli.js
npm@2.2.0 /Users/Brad/.node/lib/node_modules/npm
It worked   

Why does the above show npm@2.20 yet npm -v from the command line returns 1.4.28"

@pine3ree

This comment has been minimized.

Show comment
Hide comment
@pine3ree

pine3ree Jan 18, 2015

same here:

npm ERR! cb() never called!

node v0.10.35
npm 2.2.0 and 2.1.17

kind regards

pine3ree commented Jan 18, 2015

same here:

npm ERR! cb() never called!

node v0.10.35
npm 2.2.0 and 2.1.17

kind regards

@othiym23

This comment has been minimized.

Show comment
Hide comment
@othiym23

othiym23 Jan 19, 2015

Contributor

Why does the above show npm@2.2.0 yet npm -v from the command line returns 1.4.28

Because the Node installers from Joyent haven't included the latest stable version of npm since sometime last summer, due to a policy decision on the part of the Node release team at Joyent.

@zddhub, @Alex0007, @rich66, @krokofant, @pine3ree – please see #5920 (comment)

The issue you're seeing is probably real, and also completely unrelated to the original bug on this issue. I'm going to lock this issue now, but please open a new issue with further details (in particular, links to gists containing either npm-debug.log files from failed installs, or the output of running the failing command with -ddd). Thanks!

Contributor

othiym23 commented Jan 19, 2015

Why does the above show npm@2.2.0 yet npm -v from the command line returns 1.4.28

Because the Node installers from Joyent haven't included the latest stable version of npm since sometime last summer, due to a policy decision on the part of the Node release team at Joyent.

@zddhub, @Alex0007, @rich66, @krokofant, @pine3ree – please see #5920 (comment)

The issue you're seeing is probably real, and also completely unrelated to the original bug on this issue. I'm going to lock this issue now, but please open a new issue with further details (in particular, links to gists containing either npm-debug.log files from failed installs, or the output of running the failing command with -ddd). Thanks!

@npm npm locked and limited conversation to collaborators Jan 19, 2015

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.