gix locking leaves stale lock files
#30
Assignees
Labels
bug
Something isn't working
Comments
Jake-Shadle
added a commit
that referenced
this issue
Sep 29, 2023
As pointed out in #30, gix's locking mechanism is insufficient in the face of SIGKILL or other process interruption that can't be caught by gix's signal handler, in addition to the giant footgun that tame-index doesn't actually hook that signal handler for you, meaning applications using it that forget to hook it also run into issues. In addition, I raised #17 while doing crate-ci/cargo-release#693 (https://github.com/crate-ci/cargo-release/pull/693/files/012d3e9a7be23db14096e6a0d41cea7528f9348c#r1301688472) as right now tame-index can perform mutation concurrently with cargo itself, or potentially read partial data while it is being written. This PR resolves both of these issues by forcing all R/W operations on indexes to take a `&FileLock` argument, as well as providing a `LockOptions` "builder" to create file locks. These locks are created using flock on unix and LockFileEx on windows, meaning they can properly be cleaned up by the OS in all situations, including SIGKILL and power loss etc, unlike gix's locks, and is the same mechanism that cargo uses for its global package lock, meaning downstream users can ensure they play nicely with cargo. The lock facilities are part of the public API of tame-index as I opted to roll my own implementation instead of using fslock, as it is very outdated, and doesn't support timeouts. This does mean a lot of unsafe has been added, but it is tested and not _too_ bad. This can potentially be moved out to a separate crate in the future, but is fine for now. This means it could be used to resolve rustsec/rustsec#1011, and is something I will use in cargo-deny for the same thing, protecting access to the advisory database during mutation. It should also be noted that one can also just construct a `FileLock::unlocked()` to satisfy the API, without actually performing any locking, for cases where it's not needed/testing/etc. Resolves: #17 Resolves: #30
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
If the process is abruptly terminated (e.g. by a
SIGKILLor a power outage) when fetching the crates.io index over git,gixwill leave a stale lock file and prevent any future operations with the index: GitoxideLabs/gitoxide#1026To Reproduce
Steps to reproduce the behavior:
SIGKILLExpected behavior
The locks should be cleaned up when the process terminates.
Additional context
gixseems to implement the same locking asgit, which is broken by design. On Linux we need theflock()syscall that cleans up the locks as soon as the process terminates. A cross-platform wrapper for it is implemented in thefslockcrate. Unfortunately the crate does not provide the functionality to wait for a lock for a specific time, so this will have to be either contributed upstream or hand-rolled.The text was updated successfully, but these errors were encountered: