fix: guard fcntl.flock(LOCK_UN) with try/except in 5 files#27909
Open
vanthinh6886 wants to merge 1 commit into
Open
fix: guard fcntl.flock(LOCK_UN) with try/except in 5 files#27909vanthinh6886 wants to merge 1 commit into
vanthinh6886 wants to merge 1 commit into
Conversation
On POSIX systems, fcntl.flock(LOCK_UN) can raise OSError (e.g. EBADF if the fd was already closed by another thread, or EINTR on signal delivery). When this happens in a finally block, the subsequent fd.close() is skipped, leaking the file descriptor and potentially holding the lock indefinitely. The msvcrt (Windows) path in all these files already wraps the unlock in try/except, but the fcntl path did not — an inconsistency that this commit fixes. Files fixed: - tools/environments/file_sync.py (sync_back lock) - tools/memory_tool.py (memory write lock) - tools/skill_usage.py (skill usage tracking lock) - cron/scheduler.py (tick lock) - hermes_cli/auth.py (credential pool lock)
Collaborator
This was referenced May 18, 2026
|
Board James triage pass: this PR's |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
On POSIX systems,
fcntl.flock(LOCK_UN)can raiseOSError(e.g.EBADFif the fd was already closed, orEINTRon signal delivery). When this happens inside afinallyblock, the subsequentfd.close()is skipped — leaking the file descriptor and potentially holding the lock indefinitely.The
msvcrt(Windows) path in all these files already wraps the unlock intry/except, but thefcntlpath did not. This inconsistency means the bug only manifests on Linux/macOS.Fix
Wrap
fcntl.flock(lock_fd, fcntl.LOCK_UN)intry: ... except (OSError, IOError): passto match the existing msvcrt pattern. Zero behavioral change on the happy path; prevents fd leaks and exception masking on the error path.Files Changed
tools/environments/file_sync.pytools/memory_tool.pytools/skill_usage.pycron/scheduler.pyhermes_cli/auth.pyBefore vs After
flock(LOCK_UN)raisesOSErrorfd.close()skipped -> fd leak + lock held foreverfd.close()runs normallyflock(LOCK_UN)succeedsTests
Existing tests cover the happy path. The error path is hard to trigger deterministically (requires fd invalidation or signal delivery during unlock), but the fix is defensive and follows the same pattern already used for the msvcrt branch in each file.