lerna: Lerna bootstrap fails due to concurrency (with npm)

The latest RC version fails when running lerna bootstrap. I’m not sure when it was introduced, though, because only today builds started failing on Travis while RC3 was released 8 days ago. So, I may be actually running into two separate issues. Both turned to have the same solution, though, switching off concurrency.

The issue, at least now, can be reproduced in the following way:

p@m /workspace/test> git clone git@github.com:ckeditor/ckeditor5.git
Cloning into 'ckeditor5'...
remote: Counting objects: 6484, done.
remote: Compressing objects: 100% (71/71), done.
remote: Total 6484 (delta 32), reused 0 (delta 0), pack-reused 6407
Receiving objects: 100% (6484/6484), 1.16 MiB | 336.00 KiB/s, done.
Resolving deltas: 100% (3672/3672), done.
p@m /workspace/test> cd ckeditor5/
(master cbe80fd) p@m /workspace/test/ckeditor5> lerna bootstrap
Lerna v2.0.0-rc.3
Bootstrapping 1 packages
Preinstalling packages
Installing external dependencies
Installing hoisted dependencies into root
Pruning hoisted dependencies
FileSystemUtilities.rename    ("./package.json", "./package.json.lerna_backup")
Error: ENOENT: no such file or directory, rename '/workspace/test/ckeditor5/package.json' -> '/workspace/test/ckeditor5/package.json.lerna_backup'
    at Error (native)
NpmUtilities.installInDir     (".", ["guppy-pre-commit@^0.4.0"], {})
Error: ENOENT: no such file or directory, rename '/workspace/test/ckeditor5/package.json' -> '/workspace/test/ckeditor5/package.json.lerna_backup'
    at Error (native)
Errored while running BootstrapCommand.execute
Error: ENOENT: no such file or directory, rename '/workspace/test/ckeditor5/package.json' -> '/workspace/test/ckeditor5/package.json.lerna_backup'
    at Error (native)

When I try with --concurrency=1 the issue doesn’t seem to appear:

(master cbe80fd) p@m /workspace/test/ckeditor5> lerna bootstrap --concurrency=1
Lerna v2.0.0-rc.3
Bootstrapping 1 packages
Preinstalling packages
Installing external dependencies
Installing hoisted dependencies into root
Pruning hoisted dependencies
Symlinking packages and binaries
Postinstalling packages
Prepublishing packages
Successfully bootstrapped 1 packages.

It also proved to help with a bit more complicated situation I had on Travis: https://travis-ci.org/ckeditor/ckeditor5/builds/226105896. It worked well after disabling concurrency: https://travis-ci.org/ckeditor/ckeditor5/builds/226101027.

I can see that similar issues were already reported: https://github.com/lerna/lerna/issues/397 and https://github.com/lerna/lerna/issues/616. However, this may be the first scenario in which the issue can be easily reproduced.

Your Environment

Executable Version
lerna --version 2.0.0-rc.3
npm --version 4.0.3
node --version 6.9.1
OS Version
macOS Sierra 10.12.4

About this issue

  • Original URL
  • State: closed
  • Created 7 years ago
  • Reactions: 10
  • Comments: 22 (7 by maintainers)

Commits related to this issue

Most upvoted comments

Unfortunately, I didn’t save it as I went straight to npm-debug.log (which is usually more helpful so Lerna could mention that to the user). In the console, as I recall, there was just an info about crashing processes.

I know that the npm log indicates that some JSON was missing/invalid, but I’ve seen the same error many times in the past. Usually, a second lerna bootstrap run would help with that. So, my assumption now, when I discovered that lerna bootstrap --concurrency=1 helps even more consistently is that:

  • one Lerna process starts installing package X,
  • a second process tries to install the same package at the same time,
  • there’s some mutex failure and the second process thinks that the package is already available in npm’s cache (/Users/me/.npm) but it isn’t or is temporarily invalid at that moment,
  • the second process crashes while trying to read this file.

And why does it work when running lerna bootstrap for the second time (even concurrently)? Because the cache is already hot and all JSONs are usually already unpacked there.

Anyhow reasonable?

We finally have a reliable workaround!!!

install: travis_retry make ci-install

where the makefile does

ci-install:
	yarn;
	lerna bootstrap --mutex file:/tmp/.yarn-mutex --concurrency=1;

The key is travis_retry where it will attempt the installation 3 times. So far we have 100% success.

Same issue when run command lerna exec --parallel --stream -- npm i on node 12.13.0 and npm 6.12.0. And it works fine on node 10.10.0 and npm 6.4.1

In our case I narrowed the bug down to npm version 6.10.2. I can successfully run 6.10.1 with concurrency=8, whereas using 6.10.2 it fails every time. Looking at the changelog there were changes in this version to cache file ownership, so this sounds likely.

We’re using node 12.13.0, although I’m not sure this is relevant.

(To be clear, I’m referring to the cache lock issue, e.g. ENOENT: no such file or directory, lchown ‘/Users/xxx/.npm/_locks/staging-5e1c07f26fab6251.lock’)

nope. npm5 does not.

Do you think it would be fruitful to make an integration test that demonstrates this behavior?