Go-ipfs: bug: Unable to start daemon after unclean shutdown

[mateon1]

Version/Platform/Processor information: ipfs version 0.4.2; Windows 10 x64
(Unrecognized option 'all')

Type: bug
Area: daemon
Priority: P2

Description:
After an unclean daemon shutdown, the $IPFS_PATH/repo.lock can be left in an invalid state, preventing the daemon from launching without manual intervention (deleting the lock file).

Example, running ipfs --debug daemon:

$ ipfs --debug daemon
19:58:27.797  INFO   cmd/ipfs: IPFS_PATH D:\ipfs main.go:297
19:58:27.797 DEBUG   cmd/ipfs: Command cannot run on daemon. Checking if daemon is locked main.go:425
19:58:27.797 DEBUG       lock: Checking lock lock.go:33
19:58:27.798 DEBUG       lock: Can't lock file: D:\ipfs/repo.lock.
 reason: can't Lock file "D:\\ipfs/repo.lock": has non-zero size lock.go:45
19:58:27.798 DEBUG     fsrepo: (true)<->Lock is held at D:\ipfs fsrepo.go:258
Error: ipfs daemon is running. please stop it to run this command
Use 'ipfs daemon --help' for information about this command

[whyrusleeping]

@mateon1 thanks for the report! Our windows testing right now is definitely lacking, This issue looks like it would likely be addressed by upstream changes in the locking library we're using.

[Kubuxu]

@whyrusleeping I remember other issues where we were talking about changing the lock lib, did it happen?

[whyrusleeping]

@Kubuxu i don't think we ever got around to updating that

[Kubuxu]

I think we did: https://github.com/ipfs/go-ipfs/pull/2887

This means that the issues might be resolved in 0.4.3

@mateon1 I think you already updated to 0.4.3-rc2, can you give this issues another shot?

[mateon1]

@Kubuxu Sure. If I force kill the daemon process on 0.4.3-rc2, the lock can't be acquired for about 10 seconds (1-2 failed daemon launches), after which the daemon starts correctly.
This issue was initially caused by a blackout, and I'd rather not just switch the power off to my PC to test this, but it seems fine so far.
I'll do some more simple testing for now.

[mateon1]

I this issue seems to be fixed in 0.4.3; the lockfile is a JSON object, marking the owning process's PID. I believe if the PID exists, the lock considers itself claimed, otherwise invalid, fixing this issue.

[Iwasawafag]

It could be that problem is still there. Or maybe a little different kind of problem

I was using version 0.4.3 (binary from https://dist.ipfs.io/go-ipfs/v0.4.3/go-ipfs_v0.4.3_windows-amd64.zip) and when it exited with code 1 lock file expectedly was not removed. But on the next run it errored again simply because lock file was present, even though no process with PID from it existed and it should have been considered invalid.

Easiest way to reproduce it is to run ipfs swarm peers twice when there's no daemon running:

C:\Users\Iwasawafag>ipfs swarm peers
Error: This command must be run in online mode. Try running 'ipfs daemon' first.
Use 'ipfs swarm peers --help' for information about this command

C:\Users\Iwasawafag>ipfs swarm peers
Error: cannot acquire lock: file "C:\\Users\\Iwasawafag\\.ipfs\\repo.lock" already locked

I'm not really familiar with Go, so I can't tell what's going on here. From the go4/lock/lock.go it looks like it's only does validating for portable locks, whatever that is, even though it can make one of those checks fail by overriding OwnerPID to 0. It could be that problem is with that library, but you'll have to confirm that for yourself as I'm not competent here.... At least I found an easy way to test it!

[noxonsu]

same problem

[grmkris]

when i shutdown ipfs using ctrl+c and then trying to rerun it again. I get the error that repo.lock is alrleady locked

[Stebalien]

@kris113 windows? That won't be fixed in the next release (baking right now) but will be in the next. Lockfiles on windows will now be cleaned up by the OS.

FYI, to work around this, call ipfs repo fsck to remove the lockfile.