| Previous | Next |
| EDEADLK | EALREADY |
ENOLCK
How this differs from a contested lock
ENOLCK does not say that another process merely owns the byte range you requested. A normal conflict is typically reported with a busy or access-related result, or the caller waits when it used a blocking lock request. ENOLCK instead indicates that the kernel, filesystem, or remote lock service cannot provide the locking resources or state needed to create or track the lock.
This is especially important for long-running services that make many fine-grained POSIX record locks, or for applications using network filesystems where local and remote lock state must remain coordinated. Blind retries can multiply lock requests while leaving the original ownership and recovery problem unresolved.
Useful diagnostics
- Record the lock type, byte range, descriptor, filesystem, and whether the request used POSIX, open-file-description, or another locking API.
- Measure lock churn and verify that locks are released on all success, error, timeout, and process-exit paths.
- For network mounts, inspect the client and server lock configuration and availability before treating it as a local file problem.
- Consider coarser lock granularity or a higher-level coordination design when lock metadata becomes the bottleneck.
References
Looking for a different code? Search another status or error code.