Lock file staleness check could be more robust [JIRA: RIAK-2230] #226
Labels
Comments
Basho-JIRA
changed the title
andytill
added a commit
to andytill/bitcask
that referenced
this issue
Feb 9, 2018
…le creation Previous to this change, the OS pid was used to lock the bitcask database and prevent two bitcask instances performing write operations at the same time. However, if bitcask is not able to clean up the write locks because of a hard shutdown and another process takes that the pid in written to the lock file, bitcask is not able to take the lock even though it is the only running instance. This change uses the flock system call to obtain exclusive write access to the file across OS processes, as long as the other processes use flock to obtain the lock.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
A few days ago, we started getting {error,locked} errors on certain puts in a development environment. After some digging, I found that bitcask_lockops:delete_stale_lock/1 was incorrectly returning not_stale for bitcask.write.lock files when the pid had been reassigned (in our case to a rabbitmq beam process.) This is because it uses
kill -0, which merely verifies a process' existence, not its identity.A workaround is to stop Riak and delete all bitcask.write.lock files.
The text was updated successfully, but these errors were encountered: