Comments (6)
The same issue is present on Linux. This race also gets lost frequently for system services (which start up during system boot, and so often have long-lived processes with similar PIDs present on subsequent boots), which then fail on the next system boot.
You could fix this by:
. Storing as much as you can (on the given OS) of:
- hostname
- process start time
- process executable path
- pid
You then:
Always consider locks valid if the hostname is different from that stored in the lock file (since you can't tell if the process is still running)
If the hostname matches, then only consider the lock valid if the PID, process start time, and executable (or as many of those as you have on the given OS) is present.
Maybe store the lock file contents as JSON?
I can create some proof-of-concept code for Linux if you're interested?
from lockfile.
Thanks @tim-seoss for the offer! Would like to see such code. I esp. look for ideas on how to parse existing lock files not having that information and do the migration transparently.
from lockfile.
First, thanks a lot for your lib.
I am confused about this issue. The core of "lock file" is LOCK the file by current process, not just write the pid into file. Due to the file is locked, the certain instance of program must be running. Besides the process dies, the lock will disappear and the other instance can run and relock the file.
By reading the code, it seems lockfile does not use the mechanism above. Maybe we should check the process which pid written in the pid file is the certain process or not, using the lib.
from lockfile.
@Aulilino To clarify, the lib currently (or at least when I last checked a year ago) made the following assumption:
- If there is a process in existence with the same PID as in the lock file, then the lock is still valid (because the process which created the file must still be running, and therefore the lock should be honoured).
- If there is not a process in existence with the same PID as in the lock file, then the lock is no longer valid, and can be reissued to the calling process.
These assumptions break if:
. The process ID has been reallocated to another process entirely.
. The PID gets reallocated to another invocation of the same binary (e.g. typically because of a reboot, but this can also happy less frequently by chance in normal operation).
. The filesystem containing the lock is visible across PID namespaces (e.g. via a network filesystem, or container boundary), so that a still-running process which holds the lock is potentially invisible to the calling process.
from lockfile.
@tim-seoss thanks for the analysis. The last point about pid namespaces might be a deal breaker for many people.
So I believe this should be documented in a limitations section of the readme as well as in the package doc.
Care to send a pull request for either of these?
from lockfile.
frozen due to age.
from lockfile.
Related Issues (13)
- Failer on windows when pid is from dead process HOT 10
- return better error on Unlock/Trylock race HOT 2
- Automatic retries HOT 1
- License file is MIT but readme says the project is BSD HOT 1
- Documentation of algorithm constraints and fail on their violation HOT 2
- Locking fails in vboxfs because hard links are not possible. HOT 4
- non-recursive lock
- Stop file from being deleted (win, mac, linux) HOT 1
- Use symlinks instead of hardlinks on unix platforms HOT 7
- circular imports not allowed HOT 4
- Dependency Dashboard
- bug: deadlock caused by pid reusing HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from lockfile.