Pipe to self: "Error: Lock file is already being hold"

[alanshaw]

jsipfs cid base32 fails to start because repo is locked by jsipfs add -q

$ echo "hello world" | jsipfs add -q | DEBUG=* jsipfs cid base32
  cli daemon is off +0ms
  jsipfs EXPERIMENTAL pubsub is enabled +0ms
  jsipfs booting +2ms
  repo opening at: /Users/alan/.jsipfs +0ms
  repo init check +1ms
  repo:version comparing version: 7 and 7 +0ms
  repo init null { config: true, spec: true, version: undefined } +3ms
  repo:lock locking /Users/alan/.jsipfs/repo.lock +0ms
  repo:lock Error: Lock file is already being hold
  repo:lock     at options.fs.stat (/Users/alan/Code/protocol-labs/js-ipfs/node_modules/proper-lockfile/lib/lockfile.js:54:47)
  repo:lock     at /Users/alan/Code/protocol-labs/js-ipfs/node_modules/graceful-fs/polyfills.js:285:20
  repo:lock     at FSReqWrap.oncomplete (fs.js:155:5) +3ms
events.js:167
      throw er; // Unhandled 'error' event
      ^

Error: write EPIPE
    at WriteWrap.afterWrite [as oncomplete] (net.js:792:14)
Emitted 'error' event at:
    at onwriteError (_stream_writable.js:431:12)
    at onwrite (_stream_writable.js:456:5)
    at _destroy (internal/streams/destroy.js:40:7)
    at Socket.dummyDestroy [as _destroy] (internal/process/stdio.js:11:34)
    at Socket.destroy (internal/streams/destroy.js:32:8)
    at WriteWrap.afterWrite [as oncomplete] (net.js:794:10)

I think go-ipfs has the concept of command requirements, perhaps we need something similar i.e. jsipfs cid does not require a repo so shouldn't need to obtain a lock.

[Schwartz10]

@alanshaw unfortunately still getting this issue, with this node program:

const IPFS = require('ipfs');

const init = () => {
  const ipfs = new IPFS();

  ipfs.on('ready',  () => console.log('ready'));
  ipfs.on('error', err => console.log(err));
};

init();

The error is being caught in the error event listener:

{ Error: Lock file is already being hold
    at options.fs.stat (<repo-path>/node_modules/proper-lockfile/lib/lockfile.js:54:47)
    at <repo-path>/node_modules/graceful-fs/polyfills.js:285:20
    at FSReqCallback.oncomplete (fs.js:160:5) code: 'ELOCKED', file: '/Users/<me>/.jsipfs' }

node: v11.9.0
ipfs: ^0.34.4

Running this program several times in a row (one after another, not simultaneously) will cause the error to happen. If I stop, wait a bit, and run it again, it sometimes works. Seems like it could be related to #229. How can i help?

[KrishnaPG]

Same problem here. During the development, it is imperative that the app will be restarted with code modifications frequently, which leads to the "Lock file is already being hold" error frequently.

Previous instance holding the lock is fine, but how to override / release it in new instance ? Is there anything we can do in the code to resolve this situation and force the node to start ??

This may turnout to be a problem in production also, if this file-system lock thing cannot be resolved programatically.

[ohager]

Same problem here. During the development, it is imperative that the app will be restarted with code modifications frequently, which leads to the "Lock file is already being hold" error frequently.

Previous instance holding the lock is fine, but how to override / release it in new instance ? Is there anything we can do in the code to resolve this situation and force the node to start ??

This may turnout to be a problem in production also, if this file-system lock thing cannot be resolved programatically.

You could remove the repo.lock folder within the repo directory. This is not elegant, but works for me (so far).

[ptoner]

I also frequently get this when running unit tests that create an instance and then fail for whatever reason. When I run the tests again this will almost always happen. I also handle it by manually deleting the repo.lock folder.

[alanshaw]

Only one IPFS node can access an IPFS repo at a time.

Use the repo option to specify a directory if you need to start up multiple nodes. Please see this example for further instructions on how to run multiple nodes simultaneously on the same computer.

In tests you should use a temporary directory that you clean up after the node has shutdown. You could also use https://github.com/ipfs/js-ipfsd-ctl to make this job easier.

[ptoner]

Only 1 is running at a time. It starts, it crashes, and then it doesn't start again. I've resolved it by deleting the repo.lock file in code. But it's pretty confusing.

[alanshaw]

If you retry after 10s proper-lockfile should consider the lock stale and succeed. I'd still recommend using a temporary repo if you're running tests where things may fail at any time.

I think a PR to proper-lockfile to add an option for removing the lock on uncaught exception /unhandled rejection might be an option but you should open an issue first at https://github.com/moxystudio/node-proper-lockfile/issues to see if it would be welcome.

[ptoner]

It happens most often with tests, but it also sometimes happens when the app I'm testing crashes. I'll look into the temp repo for the tests.

The 10s thing is helpful info and makes sense because I'm usually able to restart it if I wait a bit.

[ungarson]

I came here because of the problem in my js, the problem was that I called IPFS.create() two times (in two different places), and so I guess they somehow conflicted. Solved it by initializing it in one place. Hope it might help people like me :)

[bn185068]

@ungarson thanks for your post. This solved the problem for me. I built an api and every time I call a specific route, I was calling await IPFS.create() in the route's logic, which I guess was reinitializing the repo and hitting the LockExistsError. Solved it by initializing the repo once in my app.js file, and then setting it globally for reuse. Something like this:

const IPFS = require('ipfs-core')
async function initGlobalIPFS() {
    global.IPFS = await IPFS.create()
};
initGlobalIPFS()

This works, however, I'm not clear on why this works. Does anyone have any reference documentation that I can read through to get a better understanding of what is happening when calling the .create() method and how IPFS repos work. Would love to understand it more, but having difficulty finding docs or reference materials that explain it. Thanks!

[achingbrain]

@bn185068 please can you ask on https://discuss.ipfs.io ? You're more likely to get a better answer there, this repo is for reporting bugs/issues with js-ipfs and not asking how-do-I type questions.

[bn185068]

@achingbrain apologies. I assumed since I'm reporting that I also experienced this "LockExistsError" error while using this package, that it was appropriate to report how I solved it on the thread where others are experiencing the same error. Didn't realize I couldn't ask a question about the code that I'm using in an issue attached to that code's repo. I'll ask my question about the js-ipfs code on the ipfs discussion forum. Thanks for the reference link.