Dep: Waiting for lockfile :Locked by other process

[SamuelBWasserman]

I get this error when running dep status or dep ensure on a new project

[sdboyer]

i'm guessing you've fallen in an improbable but unfortunate hole in our current on-disk locking behavior - a previous dep run left behind $GOPATH/pkg/dep/sm.lock with a pid that was later taken over by a long-running/daemon process. (we have an open, but unfinished PR to improve this, among other things with our locking strategy)

if you're sure there isn't another dep process running, you can just rm $GOPATH/pkg/dep/sm.lock, and you should be in good shape.

next time, if you could follow the issue template, it would be helpful.

[SenHeng]

Sorry for digging up this old issue. I had the same problem, but that was because dep created a separate /vendor.orig folder that basically replicated the /vendor folder. The sm.lock file didn't exist on my end. Simply deleting the vendor.orig folder solves the problem.

inotify_init: too many open files
waiting for lockfile /go/pkg/dep/sm.lock: Locked by other process

[brianjmurrell]

In my case, I suspect that a previous run of dep was interrupted and has left this lock file around.

Does dep not clean up lock files (and any other state it creates) when it's interrupted?

[brianjmurrell]

Maybe dep's caller in this case was too aggressive with trying to kill the process tree that dep was in and escalated the kill signals to a SIGKILL too quickly.

Can you confirm that dep does catch signals and tries to clean up gracefully when it catches any? Which signals are being caught for graceful cleanup? Any of TERM, INTR, HUP? Any others?