daemon leaves behind api file lock on error

[hackergrrl]

When the daemon hits an error on load like #228, it will leave around the ~/.ipfs/api file lock.

go-ipfs seems to be smart about detecting this and cleaning it up, but it will inhibit future invocations of the js-ipfs daemon.

[daviddias]

(@whyrusleeping can confirm) go-ipfs checks if the daemon is indeed on and if it doesn't find anything on the port left behind, it just deletes the lock and spawns the daemon.

[hackergrrl]

great, so the work is

• clean up the api lock on daemon error
• check if the daemon is on on start-up and clear the lock if not

[daviddias]

exactly :)

[daviddias]

@noffle would you like to handle this one? :)

[hackergrrl]

Sorry David, I don't have the bandwidth right now for this. Feel free to reassign.

[daviddias]

@victorbjelkholm does this look like something you can take on? :) Thank you

[dignifiedquire]

Just checked the go code, and we are actually not doing what go does at all. In go the api file is deleted on closing, but does not stop the daemon from starting up. Rather it is simply overwritten.

For locking the repo to a single daemon a file called repo.lock is used which uses os level checks to figure out who the file belongs to (https://github.com/ipfs/go-ipfs/blob/master/repo/fsrepo/lock/lock.go)

[dignifiedquire]

It looks like the best bet for doing this is using

• https://github.com/joyent/node-lockfd for unix
• Replicating https://github.com/camlistore/go4/blob/master/lock/lock.go in js

and using those for repo.lock.