lockfile-progs

lockfile [options] filename...

-r retries
    Specifies the maximum number of attempts to acquire the lock. If set to -1, it will retry indefinitely. Default is 9.

-l lifetime
    Sets the maximum age (in seconds) of the lock file. If the lock file is older than this, it is considered stale and removed. Default is 0 (no lifetime limit).

-s
    Operates silently; suppresses error messages to standard output or standard error. Only the exit status indicates success or failure.

-!
    Inverts the exit status; exits with 0 on failure and 1 on success. Useful for 'if lockfile ...; then ... else ... fi' constructs.

-ml
    Make the lock file a symlink to the process's PID. This helps in identifying which process holds the lock and provides a mechanism for robust stale lock detection.

-t timeout
    Sets the time (in seconds) to wait between retries when attempting to acquire a lock. Default is 8 seconds.

filename...
    One or more files for which a lock is to be acquired. For each file, a corresponding lock file (e.g., .filename.lock) is created.

The lockfile-progs package provides a suite of programs designed to manage file-based locks, primarily to ensure that multiple processes do not simultaneously access or modify shared resources, thus preventing data corruption and race conditions. While the package itself is not a single command, its most prominent utility is the lockfile command. These tools are commonly used in scenarios requiring atomic locking, such as managing mail spools, NFS files, or any other shared data where mutual exclusion is critical.

The principle behind these programs is to create a unique lock file (often a 'dot-file' or a link) in an atomic operation. If the creation succeeds, the lock is acquired. If it fails, another process already holds the lock. The utilities handle retry mechanisms, timeouts, and can even clean up stale or expired lock files, providing a more robust locking solution than simple file creation checks.

Other utilities in the suite include dotlockfile (for traditional mail spool locking), mail-lock, mail-unlock, and mail-touchlock (specific to mail operations), and nfs-lock (for NFS-specific locking considerations).

File-based locking, while simple, has limitations. It relies on the atomicity of underlying file system operations (like link(2) or mkdir(2)) which might behave inconsistently across different NFS implementations. Deadlocks can occur if processes do not properly release locks or if a process crashes while holding a lock and the stale lock cleanup isn't sufficient. These utilities do not provide advisory locking (like flock(1) or fcntl(2)), meaning applications must explicitly check for and honor the presence of lock files.

The primary locking mechanism employed by lockfile-progs is 'dot-locking' or 'link-locking'. This involves attempting to create a unique file (e.g., .filename.lock) using an atomic operation like link(2) to a unique temporary file, or atomically creating a directory (for 'dot-directory' locks). The atomicity ensures that only one process can successfully acquire the lock at any given moment. This differs from advisory locking (like flock(1)) where the kernel manages locks, and applications must explicitly request and respect them. File-based locks are external to the kernel and rely on agreement between applications.

The core strength of these utilities lies in their use of atomic file system operations for lock acquisition. This means the operation to create the lock either fully succeeds or fully fails, preventing race conditions where multiple processes might incorrectly believe they have acquired a lock. Furthermore, features like configurable retries, timeouts, and stale lock detection (especially with the -ml option for PID-based locks) contribute to the robustness of these locking solutions, making them suitable for environments where processes might crash or become unresponsive.

The concept of using lock files for mutual exclusion dates back to the earliest days of Unix, especially for critical system resources like mail spools. The `dot-locking` mechanism (creating files like `.filename.lock`) became a de facto standard. The `lockfile-progs` package emerged to standardize and enhance these common locking utilities, providing robust, configurable tools that handle various edge cases like stale locks and retries, evolving from simple shell script implementations to more reliable compiled binaries.

flock(1), fcntl(2), link(2), mkdir(2), mail(1)