When I try to flock some file on a weka file system it failed because some other client has already hold the lock, I can't find out which process/host locked it. How can I force the client to unlock the file on weka?
-
NFS v3 or v4? (Please add this information to your question.) – roaima Aug 30 '23 at 10:07
-
@roaima I‘m actually using [wekafs](https://docs.weka.io/overview/about) It's not based on NFS v3/v4 protocol, it's a posix compliant filesystem with a group of backend servers – konchy Aug 30 '23 at 12:12
-
3Then please don't describe it in your question as NFS. Or if that's the protocol same question stands (3 or 4) but qualify that it is a different thing, "a Network File System called wekafs", for example – roaima Aug 30 '23 at 12:59
1 Answers
In general, there's no way to unlock a file from a client for a network file system, not NFS and I assume that other file systems as well. Some file systems allow releasing locks from the server side.
On the client the only way you can achieve this is to mv the file and create a new file with the same name and content but a different inode:
mv $FILE $FILE.locked; cp -p $FILE.locked $FILE
This will rename the locked file and add it a .locked suffix, and than copy it back to the original filename. Now you'll have a file with the same content and attributes as the original file, but since it will have a new inode it will not be locked (The .locked file with the original inode, however, will still remain locked).
You should understand the implications of that, though: If there are processes that still hold file descriptors to the original file (either on the same client or other clients), they will now hold a file descriptor to the old file with the .locked suffix and not to the new file with the same name, so any change you perform in the new file will not be reflected in those processes. Only processes that a file with that name after the mv / cp will use the new file.
- 3,683
- 9
- 21