Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cleanup stale lock files in the .lsp-locks directory #6816

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

JoshuaBatty
Copy link
Member

@JoshuaBatty JoshuaBatty commented Jan 6, 2025

Description

I noticed there were quite a few old stale lock files in the .lsp-locks directory. We now check that the PID is active for each file in this directory, if it's not active then it's removed.

Checklist

  • I have linked to any relevant issues.
  • I have commented my code, particularly in hard-to-understand areas.
  • I have updated the documentation where relevant (API docs, the reference, and the Sway book).
  • I have added tests that prove my fix is effective or that my feature works.
  • I have added (or requested a maintainer to add) the necessary Breaking* or New Feature labels where relevant.
  • I have done my best to ensure that my PR adheres to the Fuel Labs Code Review Standards.
  • I have requested a review from the relevant team or maintainers.

@JoshuaBatty JoshuaBatty requested a review from a team as a code owner January 6, 2025 23:33
@JoshuaBatty JoshuaBatty self-assigned this Jan 6, 2025
@JoshuaBatty JoshuaBatty added the language server LSP server label Jan 6, 2025
assert!(!lock_path.exists(), "Lock file should be removed");

// Cleanup after test
test_lock.release().expect("Failed to release test lock");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: not a biggie, maybe we should use tempfile to ensure file/dir cleanup (automatically done when var goes out of scope - even if a test fails mid-way)

Comment on lines +143 to +144
/// Cleans up all stale lock files in the .lsp-locks directory
/// Returns a vector of paths that were cleaned up
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit:

Suggested change
/// Cleans up all stale lock files in the .lsp-locks directory
/// Returns a vector of paths that were cleaned up
/// Cleans up stale lock files in the .lsp-locks directory.
/// A lock file is considered stale if:
/// - It has a .lock extension
/// - Either its contents cannot be parsed as a valid PID
/// - Or the PID it contains is no longer active
///
/// Returns paths of the lock files that were removed.

Comment on lines +153 to +170
if let Some(ext) = path.extension().and_then(|ext| ext.to_str()) {
if ext == "lock" {
if let Ok(mut file) = File::open(&path) {
let mut contents = String::new();
if file.read_to_string(&mut contents).is_ok() {
if let Ok(pid) = contents.trim().parse::<usize>() {
if !Self::is_pid_active(pid) {
remove_file(&path)?;
cleaned_paths.push(path);
}
} else {
remove_file(&path)?;
cleaned_paths.push(path);
}
}
}
}
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: reduced nesting

Suggested change
if let Some(ext) = path.extension().and_then(|ext| ext.to_str()) {
if ext == "lock" {
if let Ok(mut file) = File::open(&path) {
let mut contents = String::new();
if file.read_to_string(&mut contents).is_ok() {
if let Ok(pid) = contents.trim().parse::<usize>() {
if !Self::is_pid_active(pid) {
remove_file(&path)?;
cleaned_paths.push(path);
}
} else {
remove_file(&path)?;
cleaned_paths.push(path);
}
}
}
}
}
// Skip non-lock files
if path.extension()
.and_then(|ext| ext.to_str())
.map_or(false, |ext| ext == "lock")
{
let contents = match fs::read_to_string(&path) {
Ok(content) => content,
Err(_) => continue,
};
let should_remove = contents.trim()
.parse::<usize>()
.map_or(true, |pid| !Self::is_pid_active(pid));
if should_remove {
remove_file(&path)?;
cleaned_paths.push(path);
}
}

Copy link
Contributor

@zees-dev zees-dev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Left a few optional minor improvements (maybe opinionated here); nothing major - feel free to use them 😄
LGTM 👍

let mut contents = String::new();
if file.read_to_string(&mut contents).is_ok() {
if let Ok(pid) = contents.trim().parse::<usize>() {
if !Self::is_pid_active(pid) {
Copy link
Contributor

@alfiedotwtf alfiedotwtf Jan 7, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've stopped using PID files because I've been burned by this before - the call to is_pid_active() can still return true on servers with long uptimes that are burning through processes, causing PIDs to wrap. On some systems the PID space is as small as 32768 but on my beast it's:

> cat /proc/sys/kernel/pid_max 
4194304

Instead, I now use advisory locking (the following is code from forc-telemetry), which also has the nice advantage in that it's shorter code as you don't need to read the file:

self.logfile_lock = match Flock::lock(logfile, FlockArg::LockExclusiveNonblock) {
        Ok(logfile_lock) => Some(logfile_lock),
        Err((_, Errno::EWOULDBLOCK)) => {
            // Silently exit as another Collector is already running
            exit(0);
        }
}

remove_file(&path)?;
cleaned_paths.push(path);
}
} else {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think the else should do clean up as there's a race condition - the other process could be in the middle of writing it's PID into the lockfile itself 😅

@kayagokalp
Copy link
Member

kayagokalp commented Jan 7, 2025

This made me check the forc locks and same thing happens there too, without any active forc process I have more than 50 locks in ~/.forc/.locks 🤯

edit: opened #6818

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants