Nuxt.js: Lock dir not cleaned on compromised lock & fatal error lock is already released

Created on 21 Mar 2019 · 25Comments · Source: nuxt/nuxt.js

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)}

bug-report

Source

pimlie

👍21

Most helpful comment

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

Mnwa on 27 Mar 2019

👍4

All 25 comments

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.

pi0 on 22 Mar 2019

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

highalps on 22 Mar 2019

👍3

@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.

pimlie on 22 Mar 2019

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.

pierreyoda on 22 Mar 2019

👍4

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

cyberbound on 22 Mar 2019

For people here, see my comment here about possible causes: https://github.com/nuxt/nuxt.js/issues/5331#issuecomment-475852783

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.

pimlie on 23 Mar 2019

👍1

--no-lock flag helps

awd-studio on 24 Mar 2019

👍3 👎1

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 🤔🤔

loonpwn on 25 Mar 2019

👍2

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: https://github.com/moxystudio/node-proper-lockfile/issues/82

pimlie on 25 Mar 2019

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

shivgarg5676 on 25 Mar 2019

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

pimlie on 25 Mar 2019

but we are using v2.4.5

shivgarg5676 on 25 Mar 2019

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.

pimlie on 25 Mar 2019

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

Pietro89 on 25 Mar 2019

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

shrpne on 25 Mar 2019

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

Mnwa on 27 Mar 2019

👍4

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?

nmfzone on 31 Mar 2019

@nmfzone The same situation with u.

nepaul on 1 Apr 2019

@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

pimlie on 1 Apr 2019

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

nacho-moby on 3 Apr 2019

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

nmfzone on 3 Apr 2019

@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).

nmfzone on 4 Apr 2019

@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.

pimlie on 4 Apr 2019

$ 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



md5-a1dcd2c0c03e1bfef1dd0a3bc902007f



nuxt generate --no-lock