-
-
Notifications
You must be signed in to change notification settings - Fork 115
FileNotFoundError: [Errno 2] No such file or directory: '/tmp/locks/my_lock.lock' #176
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
Comments
It should, there must be something else going on, never seen this myself. A repro with a docker image would be nice... |
Also running into this on macos, python 3.10.8 |
Does some other process delete the lock? Generally, it's not a great practice to have lock files under |
For me the lock is not in a temporary directory
A quick |
PR welcome 🤔 perhaps we should do a mkdir on the parent of the file to ensure that folder exists at the time of creation 🤔 could also be a permission issue, and Python surfaces it with this FileNotFoundError; we would need to investigate if you can replicate. Otherwise, a docker image doing that would be helpful. |
Ah ignore me, red herring. All good
…On Tue, Dec 6, 2022 at 5:12 PM Bernát Gábor ***@***.***> wrote:
PR welcome 🤔 perhaps we should do a mkdir on the parent of the file to
ensure that folder exists at the time of creation 🤔 could also be a
permission issue, and Python surfaces it with this FileNotFoundError; we
would need to investigate if you can replicate. Otherwise, a docker image
doing that would be helpful.
—
Reply to this email directly, view it on GitHub
<#176 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAEFQS3H4REFOBTPJT6TGHDWL7P6BANCNFSM6AAAAAASQBXEHE>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
By chance, this isn't Mac OS X Leopard, and a known OS issue that could cause a FileNotFoundError? (Patched 2011) http://www.weirdnet.nl/apple/rename.html |
I don't have access to an osx box to test this, but I wonder if the unix behavior of emptying tmp was retained in osx and perhaps they're also deleting the folder inside of tmp? Just a thought |
On my osx box, I can confirm that osx does retail the unix behavior of emptying tmp. I can confirm that osx will delete folders in Considering this is a "repeated" issue, I'm thinking the MacOS expiring behavior may not be the issue. tmp is cleared on reboot, and this is the error you would expect if Is it possible rebooting is causing the error? Related Stack post: https://superuser.com/questions/187071/in-macos-how-often-is-tmp-deleted |
yeah I would definitely agree that reboot is involved. This is the same behavior as other Unix derivatives. If the folder inside of /tmp/ is part of some image or a docker; then it is very possible that the folder creation date is tagged as when the image was created which could cause the folder to be immediately flagged and deleted upon startup of the image/instance. I think that using /tmp/ for locks is a deeply bad practice; I could see two routes. check for directory existence and do a mkdir if needed; or instead throw a clearer error to tell the user that their subdirectory is missing. I personally prefer the second as I worry about side effects of automatic directory creation when a user isn't expecting it - particularly if there are symlinks, hardlinks, remote filesystems, etc involved. I just think that might be a big can of worms that we don't want to get involved in. |
To clarify, on MacOS folders are checked for deletion by modification time, not creation. Every time a file is created, the modification time is updated. Except... filelock does not actually delete the lock on release on MacOS (I see there have been contention over this, but I am still not sure of the nuance of lock deletion on unix). This means that the file is only created once, and so the folder modification time is only updated once. Even if the lock continues to be used after that, it will not update the creation time of the lock, nor the modification time of the folder. As such, both will be deleted by the system ~72 hours after initial use. The solution is for the application code to create the directory if it doesn't exist. @connormason is it possible this could be the solution? I don't actually think using
Just to answer your question. Yes, passing |
Well, i ran into this issue and solved it. |
I have been intermittently seeing this error (was thinking possibly due to a race condition), but one of my coworkers started running into this issue repeatedly. Any idea why this could be happening? Reproducing solely on macOS
Code I'm running:
I see that in
_acquire()
theos.O_CREAT
flag is being provided toos.open()
, so shouldn't the file be created if it does not exist?Sanitized traceback:
The text was updated successfully, but these errors were encountered: