proper-lockfile errors after sleep

Question

proper-lockfile errors after sleep

alanshaw opened this issue 6 years ago · 12 comments

Start an IPFS daemon
Put your computer to sleep for 30s

💥

/Users/alan/Code/protocol-labs/js-ipfs/node_modules/proper-lockfile/lib/lockfile.js:181
        onCompromised: (err) => { throw err; },
                                  ^

Error: Unable to update lock within the stale threshold
    at options.fs.utimes (/Users/alan/Code/protocol-labs/js-ipfs/node_modules/proper-lockfile/lib/lockfile.js:109:21)
    at FSReqWrap.oncomplete (fs.js:141:20)

Answer 1 · 2019-01-22T15:51:56.000Z

Silly question, but since everything is immutable, why do we need to lock the repo? There would need to be some inter-process guarding around things like the MFS root hash or the pin sets to prevent simultaneous writes, but for the most part shouldn't it all be append-only?

Answer 2 · 2019-01-22T15:54:23.000Z

Or are we just using the wrong data store?

Answer 3 · 2019-01-22T16:06:36.000Z

brainstorming this with @satazor (proper-lockfile creator)

Answer 4 · 2019-01-28T12:47:39.000Z

Silly question, but since everything is immutable, why do we need to lock the repo? There would need to be some inter-process guarding around things like the MFS root hash or the pin sets to prevent simultaneous writes, but for the most part shouldn't it all be append-only?

We had previously looked at making locking optional, but there were concerns about doing that. I think a primary concern would be protecting against multi-tenancy issues, especially if we end up with different versions of go/js. I haven't done much exploration into this though.

brainstorming this with @satazor (proper-lockfile creator)

@hugomrdias any update on this? Do we need the staleness check? We previously didn't have it and it was only added with proper-lock. Perhaps an intermediary solution would be to do some checking in the onCompromised option and refresh the lock if it was a staleness issue. This isn't ideal, but it would at least prevent these staleness issues until we have an appropriate resolution.

Answer 5 · 2019-01-28T12:52:22.000Z

We had a discussion last week. The issue is that proper-lockfile fails if the time it took to update the lock was greater than the threshold. Now, this doesn't necessarly mean that the lock was compromised but, at the moment, proper-lockfile throws. We have discussed in doing an extra check to prevent it from throwing. That will solve the sleep scenario as well as the one in which the event loop is blocked for quite some time.

Answer 6 · 2019-01-28T14:55:00.000Z

@satazor do you think you'll be able to implement a fix soon? This issue is a big problem for anyone using a JS IPFS daemon with IPFS companion (amongst other reasons).

Answer 7 · 2019-01-28T15:22:25.000Z

@satazor will not be able to take this, i will implement the extra check in proper-lockfile

Answer 8 · 2019-03-01T14:30:12.000Z

I'm seeing the sleep issue too. Not sure how to help, though... if someone with more context could provide some pointers I'd be happy to take a look.

Answer 9 · 2019-03-06T20:18:58.000Z

can you please validate that this PR moxystudio/node-proper-lockfile#74 fixes the problem pls ?

Answer 10 · 2019-03-07T11:54:07.000Z

@hugomrdias would you mind submitting a PR here so I can do the same for js-ipfs?

Answer 11 · 2019-03-07T15:41:25.000Z

i will once i release proper-lockfile
can link it in js-ipfs and validate the fix? i pushed some more commits to the branch just now

Answer 12 · 2019-03-13T12:13:53.000Z

Should be resolve in v0.26.3