Cli: [BUG] `lchown` error when accessing installation lock file when running multiple installations in parallel.

[SimonSchick]

What / Why

NPM fails to due to create(?) locks (not package-lock.json) during installation.

When

• Appears to happen when performing multiple parallel installs.

Where

• https://dev.azure.com/definitelytyped/DefinitelyTyped/_build/results?buildId=24313
• Also occurs locally on MacOS

How

Current Behavior

• Will occassionally fail to lchown npm lock files (not package-lokc.json).

Steps to Reproduce

• See where section.
• It is possible to repro this by performing the following steps:
  
  
  
  • Clone my fork of DT and checkout my branch related to this PR
  
  
  • Initialise via npm install
  
  
  • Run npm test node
  
  

Expected Behavior

• Locking does not failed.

Who

• Unsure

References

• https://github.com/microsoft/types-publisher/issues/707

[sandersn]

Also occurs locally on Linux with the same repro steps, eg

npm ERR! syscall lchown
npm ERR! path /home/nathansa/.npm/_locks/staging-33722a1ecded5100.lock
npm ERR! errno -2
npm ERR! enoent ENOENT: no such file or directory, lchown '/home/nathansa/.npm/_locks/staging-33722a1ecded5100.lock'
npm ERR! enoent This is related to npm not being able to find a file.

[sandersn]

Seems to happen less when I switch to node 11.0.0 + npm 6.7.0.

[Flarna]

Node 11.0.0 is a really strange version as node 11 is EOL since a while. Maybe try the current LTS 12.13.1? Or it's maybe the older NPM version bundled with node 11 which avoids this.

[sandersn]

Yeah, I was just travelling backward through the versions I have installed until I found a non-problematic version. The older npm version is very likely the variable.

[SimonSchick]

@sandersn maybe perform a manual binary search through versions? 😛

[Cawllec]

Experiencing this bug when using Lerna consistently, which is unfortunately causing issues in our build process.
Error message:

lerna ERR! npm install stderr:
  | npm ERR! code ENOENT
  | npm ERR! syscall lchown
  | npm ERR! path /root/.npm/_locks/staging-3f138bd09ee0de58.lock
  | npm ERR! errno -2
  | npm ERR! enoent ENOENT: no such file or directory, lchown '/root/.npm/_locks/staging-3f138bd09ee0de58.lock'
  | npm ERR! enoent This is related to npm not being able to find a file.
  | npm ERR! enoent

This is when using the node:latest-alpine docker image, which currently uses the versions:
node: 12.13.1
npm: 6.12.1

[midudev]

I can confirm this is happening to me as well with node v13.2.0 and npm 6.13.4.

Anyone has a temporary fix for this? As it's blocking some of our deployments. :(

[SimonSchick]

@midudev temp mitigation is to not run npm i in parallel or at least drastically reduce concurrency.
When dealing with the DT repo limiting it to 2 parallel installs it reduced the amount of failures by about ~90%.

[midudev]

Thanks @SimonSchick. Yes... Using no concurrency at all seems to fix the problem but the time needed for installing packages is vastly increased. :(

I wonder if the npm team is aware of this problem as this was working fine previously. Of if this is a problem caused because some inner changes on node.

[yavorski]

Hi, we have the same issue.
I am almost sure that this is some kind of race condition issue.

Temporary fix is to downgrade to [email protected].

I have tested almost every version from 6.10.2 to latest 6.13.6 and the issue is there.
I can confirm the bug is NOT related to the nodejs version, it's just related to npm version.

[raymondfeng]

We're experiencing the same issue for npm i against https://github.com/strongloop/loopback-next, which is a lerna monorepo. npm i at the root level triggers npm installation for multiple packages in parallel. Reducing the concurrency also reduces the chance of running the reported issue.

[raymondfeng]

We can get more information about the lockfile with NODE_DEBUG=lockfile npm i.

[raymondfeng]

After some debugging, I found the issue around https://github.com/npm/cli/blob/latest/lib/utils/correct-mkdir.js#L31. If npm is executed concurrently, multiple processes call chownr against ~/.npm/_locks. The implementation of chownr reads all files in the directory and try to apply chown against each of the files. Some of the files might be deleted between readdir and lchown and it leads to ENOENT.

[raymondfeng]

@isaacs Please let me know if https://github.com/raymondfeng/chownr/commit/e4c7b59fe4142995ae36c71de3435d2e2a7e4319 is the right place to fix this issue. If so, I'll try to add some tests and submit a PR.

[isaacs]

@raymondfeng That looks like a reasonable change. Yes, please do send a PR to chownr.

[raymondfeng]

@isaacs PR submitted - https://github.com/npm/cli/issues/496. Thank you for the prompt response.