npm 6.9.0 cb() error

I upgraded 6.9.0 yesterday and am now receiving the cb() not called error. I have done a lot of research and tried a couple of things but to no avail. here is the log:

0 info it worked if it ends with ok
1 verbose cli [ ‘/usr/local/bin/node’, ‘/usr/local/bin/npm’, ‘i’ ]
2 info using npm@6.9.0
3 info using node@v8.11.2
4 verbose npm-session 447708ef6c2477b4
5 silly install runPreinstallTopLevelLifecycles
6 silly preinstall ang-adapters@1.0.0
7 info lifecycle ang-adapters@1.0.0~preinstall: ang-adapters@1.0.0
8 silly install loadCurrentTree
9 silly install readLocalPackageData
10 timing stage:loadCurrentTree Completed in 6ms
11 silly install loadIdealTree
12 silly install cloneCurrentTreeToIdealTree
13 timing stage:loadIdealTree:cloneCurrentTree Completed in 0ms
14 silly install loadShrinkwrap
15 timing stage:loadIdealTree:loadShrinkwrap Completed in 1ms
16 silly install loadAllDepsIntoIdealTree
17 http fetch GET 200
virtual/@babel%2fregister 2111ms
18 silly pacote range manifest for @babel/register@^7.4.4 fetched in 2118ms
19 http fetch GET 200
20 silly pacote range manifest for chai@^4.2.0 fetched in 2871ms
21 http fetch GET 200
22 silly pacote range manifest for @babel/preset-env@^7.4.5 fetched in 3081ms
23 http fetch GET 200
24 silly pacote range manifest for body-parser@^1.19.0 fetched in 3092ms
25 http fetch GET 200
26 silly pacote range manifest for nyc@^14.1.1 fetched in 6736ms
27 http fetch GET 200
28 silly pacote range manifest for mocha@^6.1.4 fetched in 15662ms
29 http fetch GET 200
30 silly pacote range manifest for sinon@^7.3.2 fetched in 18443ms
31 timing npm Completed in 19763ms
32 error cb() never called!
33 error This is an error with npm itself. Please report this error at:
34 error https://npm.community

You could try adding a ‘console.trace()’ as discussed here to see if it gets you more information.

@godmar thank you for your response. The trace, which I forgot to include shows that npm was unable to write to the _locks folder. This was not a problem before yesterday when I updated npm but I am behind some strict firewall and computer security rules. I ended up manually moving the npm directories to a place I had control of as a user and it has since resolved my issue. My curiosity/concern still remains with what caused the issue in an update of npm.

Unable to write to a _lock folder, assuming it’s under a directory to which you should have access - such as under your Unix home directory - is a likely consequence of your having used ‘sudo’ to run npm before, which leaves root-owned files and directories in your home directory.

Been doing this 26 years and didn’t know that. Thank you very much. I learned something new today.

How so? npm is only 10 years old.

I will share my view that I perceive npm doing that as a bug, but the npm developers over the years do not seem to share this feeling. Overall, I suspect that npm has never been tested in the scenario that users who follow the provided instructions are likely to use (specifically, the default downloads set a prefix of /usr/local on a Unix or MacOS machine where any global installs subsequently require sudo unless you resort to other non-standard measures like taking ownership of /usr/local).

I like your view. And npm is only 10 years old but your sudo comment above I found out applies to many other pieces of software and I was not aware of that. Thank you again, for your help.

sudo runs a command under effective uid 0 (root); by default - although you can configure that.
Then, any file it creates will have uid 0 as the uid of the file (recall that in Unix, there’s no way to pass an owner to an open() or creat() call). That, by itself, is accepted. It would be a user error to do, for instance sudo touch ~/file and then complain that ~/file is owned by root. So in this sense you’re correct, if you’re running arbitrary commands under sudo you end up with root-owned files.

Where npm royally screws up in my view is this: under normal usage, it requires to be run via sudo as root to be able to write to, e.g. /usr/local. When it is, it still acts in the environment of the invoking user (specially, it considers the value of $HOME, particularly as the default location for its cache and lock files etc., unless overridden). Then, any files it creates in this mode need to be chown’d back to the invoking user (if they’re in the home directory). To npm’s credit, there is code in the codebase that attempts to do that - it just appears to have never been tested. By that I mean that a regular use of say sudo npm install -g leaves root-owned files every time, and wrongly chowns files to the user’s uid in /usr/local.

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.