Skip to content

Suppress potential errors when releasing filelocks on unix #25771

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.

Sign up for GitHub

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

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
+7 −2
Open

Suppress potential errors when releasing filelocks on unix #25771

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 7 additions & 2 deletions tools/filelock.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -37,6 +37,7 @@

# Modules
# ------------------------------------------------
from contextlib import suppress
import logging
import os
import threading
Expand Down Expand Up @@ -410,8 +411,12 @@ def _acquire(self):
def _release(self):
fd = self._lock_file_fd
self._lock_file_fd = None
os.unlink(self._lock_file)
fcntl.flock(fd, fcntl.LOCK_UN)
# Probably another instance of the application
# that released the file lock.
with suppress(FileNotFoundError):
os.unlink(self._lock_file)
with suppress(OSError):
fcntl.flock(fd, fcntl.LOCK_UN)
Copy link
Collaborator

@sbc100 sbc100 Nov 11, 2025

Choose a reason for hiding this comment

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

Are both of these needed to fix your issue? Or is just one or the other enough?

It seems like neither should be necessary, since if we are holding the lock we should always be able to unlock it, right? It should be impossible for another process acquire or delete the lock file until LOCK_UN, no?

Copy link
Contributor Author

@jspanchu jspanchu Nov 11, 2025

Choose a reason for hiding this comment

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

The os.unlink is what I observed to cause trouble (also seen in the issue linked in PR description). The other one, should not be necessary.

It seems like neither should be necessary, since if we are holding the lock we should always be able to unlock it, right? It should be impossible for another process acquire or delete the lock file until LOCK_UN, no?

I would think so, but in practice, os.unlink gets executed after someone else deletes it. Could it be an issue with the port, and not the filelock.py?

Copy link
Collaborator

@sbc100 sbc100 Nov 11, 2025

Choose a reason for hiding this comment

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

I would think so, but in practice, os.unlink gets executed after someone else deletes it.

Im struggling to see how anyone else could be deleting this file. But clearly it is happening, I just want to know how / why

os.close(fd)
return None

Expand Down
Loading