Race in t.p.lockfile.FilesystemLock
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| MAAS |
Invalid
|
Medium
|
Unassigned | ||
| Twisted |
Unknown
|
Unknown
|
|||
Bug Description
When Filesystem.lock() notices a stale lock its next step is to remove the lock file. If a concurrent process is performing the same operation it may be able to remove the stale lock file and write a fresh one in the interval between when the first process detects the stale lock and when the first process removes it. The result is that both processes believe they have the lock. When unlocking, the second process will notice the discrepancy: if the first process has released the lock, it will crash with FileNotFoundError (or IOError with errno=ENOENT in Python 2); if the first process still holds the lock it will crash with ValueError.
See https:/
This affects MAAS because it uses Twisted's FilesystemLock in SystemLock and its descendents.
| Andres Rodriguez (andreserl) wrote | #1 |
| Changed in maas: | |
| status: | Triaged → Invalid |
Hi!
**This is an automated message**
We believe this is may no longer be an issue in the latest MAAS release. Due to the report date of this, we are currently marking it as Invalid. If you believe this bug report still valid against the latest release of MAAS, or if you are still interested in this, please re-open this bug report.
Thanks