Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Potential race conditions in FileSessions due to deletion of lock files #1779
I'm submitting a ...
What is the current behavior?
The scenario works because of this:
If the current behavior is a bug, please provide the steps to reproduce and if possible a screenshots and logs of the problem. If you can, show us your code.
import fcntl, os flags = fcntl.LOCK_EX | fcntl.LOCK_NB fp1 = open('x.lock', 'a+') # first file handle and file descriptor for the lock file os.remove('x.lock') fp2 = open('x.lock', 'a+') # second file handle and descriptor for the lock file lock1 = fcntl.flock(fp1.fileno(), flags) # obtain lock in deleted file lock2 = fcntl.flock(fp2.fileno(), flags) # obtain 2nd lock on new file
The simple (but maybe not the desired solution) would be to not remove the lock file.
What is the expected behavior?
I went back to a very old Cherrypy Version (3.2.2), there the so called 'naive' lock file approach
Please tell us about your environment:
Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, e.g. stackoverflow, gitter, etc.)
As I've tried to explain the issue above the basic problem with the posix-locking is due to the fact that lockfiles get removed after the session has been closed. This behavior opens the door for one process/task having an open file handle to a non-longer-existing file, while another process/thread recreates this locking file and locks it a 2nd time.
I see to possible solutions:
To some extent, I wish this issue were addressed upstream in zc.lockfile. If there's a race condition present when a lock file is deleted, and not deleting the file is the recommended approach, that should be documented upstream to prevent other consumers from making this mistake and formalizing the solution (don't delete lock files or defer deletion).
If instead the zc.lockfile considers this issue an inherent design flaw and something that could be addressed in zc.lockfile itself, then I'd prefer that approach.
If someone would be willing to file the ticket upstream (mainly to describe the issue in a pure-zc.lockfile form), I'd be happy to shepherd it through.