An inter-process and inter-machine lockfile utility that works on a local or network file system.
$ npm install proper-lockfile
There are various ways to achieve file locking.
This library utilizes the mkdir strategy which works atomically on any kind of file system, even network based ones.
The lockfile path is based on the file path you are trying to lock by suffixing it with .lock.
When a lock is successfully acquired, the lockfile's mtime (modified time) is periodically updated to prevent staleness. This allows to effectively check if a lock is stale by checking its mtime against a stale threshold. If the update of the mtime fails several times, the lock might be compromised. The mtime is supported in almost every filesystem.
This library is similar to lockfile but the latter has some drawbacks:
- It relies on
openwithO_EXCLflag which has problems in network file systems.proper-lockfileusesmkdirwhich doesn't have this issue.
O_EXCL is broken on NFS file systems; programs which rely on it for performing locking tasks will contain a race condition.
-
The lockfile staleness check is done via
ctime(creation time) which is unsuitable for long running processes.proper-lockfileconstantly updates lockfilesmtimeto do proper staleness check. -
It does not check if the lockfile was compromised which can lead to undesirable situations.
proper-lockfilechecks the lockfile when updating themtime. -
It has a default value of
0for the stale option which isn't good because any crash or process kill that the package can't handle gracefully will leave the lock active forever.
proper-lockfile does not detect cases in which:
- A
lockfileis manually removed and someone else acquires the lock right after - Different
stale/updatevalues are being used for the same file, possibly causing two locks to be acquired on the same file
proper-lockfile detects cases in which:
- Updates to the
lockfilefail - Updates take longer than expected, possibly causing the lock to become stale for a certain amount of time
As you see, the first two are a consequence of bad usage. Technically, it was possible to detect the first two but it would introduce complexity and eventual race conditions.
Tries to acquire a lock on file or rejects the promise on error.
If the lock succeeds, a release function is provided that should be called when you want to release the lock. The release function also rejects the promise on error (e.g. when the lock was already compromised).
Available options:
stale: Duration in milliseconds in which the lock is considered stale, defaults to10000(minimum value is5000)update: The interval in milliseconds in which the lockfile'smtimewill be updated, defaults tostale/2(minimum value is1000, maximum value isstale/2)retries: The number of retries or a retry options object, defaults to0realpath: Resolve symlinks using realpath, defaults totrue(note that iftrue, thefilemust exist previously)fs: A custom fs to use, defaults tograceful-fsonCompromised: Called if the lock gets compromised, defaults to a function that simply throws the error which will probably cause the process to dielockfilePath: Custom lockfile path. e.g.: If you want to lock a directory and create the lock file inside it, you can passfileas<dir path>andoptions.lockfilePathas<dir path>/dir.lock
const lockfile = require('proper-lockfile');
lockfile.lock('some/file')
.then((release) => {
// Do something while the file is locked
// Call the provided release function when you're done,
// which will also return a promise
return release();
})
.catch((e) => {
// either lock could not be acquired
// or releasing it failed
console.error(e)
});
// Alternatively, you may use lockfile('some/file') directly.Releases a previously acquired lock on file or rejects the promise on error.
Whenever possible you should use the release function instead (as exemplified above). Still there are cases in which it's hard to keep a reference to it around code. In those cases unlock() might be handy.
Available options:
realpath: Resolve symlinks using realpath, defaults totrue(note that iftrue, thefilemust exist previously)fs: A custom fs to use, defaults tograceful-fslockfilePath: Custom lockfile path. e.g.: If you want to lock a directory and create the lock file inside it, you can passfileas<dir path>andoptions.lockfilePathas<dir path>/dir.lock
const lockfile = require('proper-lockfile');
lockfile.lock('some/file')
.then(() => {
// Do something while the file is locked
// Later..
return lockfile.unlock('some/file');
});Check if the file is locked and its lockfile is not stale, rejects the promise on error.
Available options:
stale: Duration in milliseconds in which the lock is considered stale, defaults to10000(minimum value is5000)realpath: Resolve symlinks using realpath, defaults totrue(note that iftrue, thefilemust exist previously)fs: A custom fs to use, defaults tograceful-fslockfilePath: Custom lockfile path. e.g.: If you want to lock a directory and create the lock file inside it, you can passfileas<dir path>andoptions.lockfilePathas<dir path>/dir.lock
const lockfile = require('proper-lockfile');
lockfile.check('some/file')
.then((isLocked) => {
// isLocked will be true if 'some/file' is locked, false otherwise
});Sync version of .lock().
Returns the release function or throws on error.
Sync version of .unlock().
Throws on error.
Sync version of .check().
Returns a boolean or throws on error.
proper-lockfile automatically removes locks if the process exits, except if the process is killed with SIGKILL or it crashes due to a VM fatal error (e.g.: out of memory).
$ npm test
$ npm test -- --watch during development
The test suite is very extensive. There's even a stress test to guarantee exclusiveness of locks.
Released under the MIT License.
![dependabot[bot] avatar](https://avatars.githubusercontent.com/in/29110?v=4 "dependabot[bot]")
![greenkeeper[bot] avatar](https://avatars.githubusercontent.com/in/505?v=4 "greenkeeper[bot]")
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent