Lock dir not cleaned on compromised lock & fatal error lock is already released

[pimlie]

Version

v2.5.1

Reproduction link

https://github.com/nuxt/nuxt.js

Steps to reproduce

• Start a build that takes some time to finish
• run: touch -t 200012311800 ./node_modules/.cache/nuxt/build-lock-*.lock
• wait for the Unable to update lock warning to be displayed
  • this appears to only ever show between webpack builds (eg when a Client/Modern/Server finishes)

• wait for the build to finish

What is expected ?

Only the warning should be displayed. Not sure why the trace is showing, probably consola feature?

What is actually happening?

• A Nuxt fatal error is printed about 'Error: Lock is already released'
• the ./node_modules/.cache/nuxt folder still contains the .lock folder (the other folder is removed)

Additional comments?

Will have a look at this, creating this issue for reference

_{This bug report is available on Nuxt community (#c8888)}

[pi0]

run: touch -t 200012311800 ./node_modules/.cache/nuxt/build-lock-*.lock

How this is happening in the real world?

Only the warning should be displayed. Not sure why the trace is showing, probably consola feature?

CLI reports all thrown exceptions to consola.error and it shows the stack trace. I think this is expected behavior to correctly show a trace of an error. We can throw non-standard new String("Error") to prevent having stack but I'm not sure if this is a good practice.

[highalps]

it occurred to me when nuxt build in version 2.5.1, i think it is not fixed 2.5.0 -> 2.5.1

[pimlie]

@highalps At what point in your build does it happen and what is the cpu but especially the io usage at that time? (a playback of nuxt build with top & iotop would be preferred) I am having difficulties to reproduce the compromised lock behaviour consistently in the real world.

It might be that the locking we implemented is too stringent, but before we can decide on how to proceed we need to know exactly when and why the lock gets compromised. And preferable we need to be able to reproduce that behaviour. Any help would be appreciated.

[pierreyoda]

This also happened to us (Nuxt 2.5.1 with Typescript).

I managed to circumvent the issue by deleting the node_modules, reinstalling all packages and building fresh. A lock file was not deleted in the node_modules/.cache/.nuxt build cache.

[cyberbound]

I have this error as well. I have deleted node_modules, updated all packages etc. Following.

[pimlie]

For people here, see my comment here about possible causes: #5331 (comment)

Bottom line is, if you are using Node v9 then upgrade to v10 (which is a lts release and had major performance improvements). If you are already on v10+, we still dont understand yet why the lock gets compromised so often in some environments.

[awd-studio]

--no-lock flag helps

[harlan-zw]

Have recently got this after upgrading to 2.5.1. Using yarn.

I'm receiving it on a docker image with node 10.7.0 running on bitbucket pipelines, build time is 77.23s. OS is ubuntu 16.

Working fine for me locally on Mac, node 10.7.0, with a build time of 167.98s.

Exact same code. Downloading entire node_modules folder each time. Weird thing is if I mount myself in the container i'm using in pipelines locally, it works fine also 🤔🤔

[pimlie]

Yesterday I noticed an issue where the lock was compromised due to a small difference in the mtime that was set on the lock file with fs.utimes and the mtime that was subsequently read back with fs.stat. I have opened an upstream issue about that here: moxystudio/node-proper-lockfile#82

[shivgarg5676]

I am also facing this issue. My prod builds are failing after installing packages. Is there any solution available?

[pimlie]

@shivgarg5676 As previously mentioned, use --no-lock on the command line. The fatal error will be removed in v2.5.2

[shivgarg5676]

but we are using v2.4.5

[pimlie]

Lock support was only added to Nuxt in v2.5.0, so if you are using v2.4.5 you are experiencing something else. Please create a separate issue for that and add a detailed reproduction.

[Pietro89]

Changing nuxt version from 2.5.1 to 2.4.5 made the problem disappear here. @pimlie

[shrpne]

upgrade from nodejs v8 to v10 resolved the issue, thx @pimlie

[Mnwa]

I'm also change my package.json from "build": "nuxt build", to "build": "nuxt build --no-lock", it's work for me

[nmfzone]

It's also happening to me, after upgrade from v2.4.5 to v2.5.1.
Here I'm using Gitlab CI with docker executor. I used build artifacts for node_modules. Below is my gitlab CI config:

ci_prepare:
  image: node:8.11.3-slim
  stage: prepare
  script:
    - yarn
    - mkdir -p node_modules/.cache
    - chmod 777 node_modules/.cache
  tags:
    - cloud
  artifacts:
    name: "$CI_COMMIT_REF_SLUG"
    expire_in: 30 mins
    paths:
      - node_modules/

unit_test:
  image: alekzonder/puppeteer
  stage: test
  script:
    - yarn test --runInBand
  tags:
    - cloud
  artifacts:
    expire_in: 30 mins
    when: on_failure
    paths:
      - tests/reports/

but, with this setup, the CI will fails in unit_test, it says

Nuxt Fatal Error
Error: EACCES: permission denied, mkdir
 '/builds/projects/node_modules/.cache'

to solve this, you can see in above config, i need to make the cache folder writeable..
but, it's not ends here. After that, the CI still fails, it says:

Nuxt Fatal Error
Error: Lock is already released  

then, I was here. So, basically the solution is to add --no-lock? or is there any other solution to fix this?

[nepaul]

@nmfzone The same situation with u.

[pimlie]

@nmfzone (& @nepaul) You are running Node v8, if possible upgrade to v10+. That might solve the issue as well, otherwise --no-lock is the only solution

[nacho-moby]

It worked nuxt generate --no-lock in v2.5.1

[nmfzone]

@pimlie Looks nice, after upgrading to Node v10.15.3. I think it's time to upgrade too. 👍

[nmfzone]

@pimlie But, It seems like breaking changes for Nuxt 2.5.x. Since Nuxt < 2.5 work in Node < 10 and Nuxt >= 2.5 will not work in Node < 10 (if they're not used --no-lock).

I think --no-lock should be added to the default package.json for Nuxt App (for now).

[pimlie]

@nmfzone It was a bug (or actually 2 bugs), not a feature. Using --no-lock on the cli or upgrading to Node v10 are therefore just quick (temporary) workarounds. Upgrading also has the benefit of a performance increase. Really, if you can upgrade to v10 you really should upgrade to v10 anyways.

• First bug was that the lock gets compromised way too often, this was caused by a mtime precision issue and should be fixed in proper-lockfile v4.1.1 (released yesterday).
• Second bug was that an error is thrown when you release a compromised lock, it was my mistake that I did not test for that behaviour so I was not aware that an error would be thrown. The pr to catch that error has already been merged and will be included in the next Nuxt release, but I am also working with the guys from proper-lockfile to change that behaviour because it felt counter-intuitive to me.

[cschweda]

$ node -v
v10.11.0

   | Nuxt.js v2.5.1                              │
   │   Running in development mode (universal)   │
   │   Memory usage: 23.3 MB (RSS: 53.5 MB)      │
   │                                             │
   │   Listening on: http://localhost:3000

Problem fixed with --no-lock as specified above.

nuxt generate --no-lock

[pimlie]

These issues should be fixed in Nuxt v2.6. If anyone still experience issues with locking please create a new issue