flock Command: Tutorial & Examples

Manage advisory file locks from shell scripts to synchronize processes and prevent concurrent access.

The flock command in Linux provides a simple interface to manage advisory file locks from the shell. It is commonly used in scripting and system administration to prevent multiple instances of a script or process from running simultaneously, thereby avoiding race conditions, data corruption, or resource conflicts. By applying exclusive or shared locks on files, flock enables safe synchronization between processes accessing shared resources.

How It Works

The flock command operates by placing an advisory lock on a specified file descriptor or file. Advisory locks are a locking mechanism where processes voluntarily cooperate to check and respect lock status. Unlike mandatory locks enforced by the kernel, advisory locks do not prevent other processes from accessing the file unless those processes explicitly check for the lock.

flock uses the same underlying mechanism as the fcntl and lockf system calls, which implement POSIX advisory locks. Locks can be:

Exclusive locks (-x): Only one process can hold an exclusive lock on a file at a time. This is used to ensure exclusive access for writing or modifying resources.
Shared locks (-s): Multiple processes can acquire shared locks simultaneously, typically for read-only access, allowing concurrent safe reading.

If a process tries to acquire a lock that conflicts with an existing lock, it will block (wait) until the lock becomes available, unless the non-blocking option is specified.

What It Is Used For

flock is widely used to coordinate access to shared resources such as files or devices in multi-process environments. Typical use cases include:

Preventing simultaneous script execution: Ensuring that only one instance of a cron job or script runs at a time.
Synchronizing access to files: Avoiding corruption when multiple processes write to the same file.
Coordinating resource usage: Managing exclusive or shared access to hardware devices or temporary files.
Implementing critical sections: Protecting code sections that must not run concurrently.

Why It Is Important

Without proper locking mechanisms, concurrent processes may interfere with each other, leading to inconsistent or corrupted data, unpredictable behavior, or deadlocks. flock provides a lightweight and easy-to-use method for scripts and programs to manage synchronization and ensure data integrity in complex systems.

How To Use It

The general syntax of flock is:

flock [options] <file|filedescriptor> <command> [arguments]

<file>: The file used as a lock reference.
<filedescriptor>: An open file descriptor number (used with -u).
<command> [arguments]: The command to execute while holding the lock.

If a command is not specified, flock will acquire the lock and wait until it is released or the process is terminated.

Common Options

-x, --exclusive: Acquire an exclusive lock (default if none specified).
-s, --shared: Acquire a shared lock.
-n, --nonblock: Fail immediately if the lock cannot be acquired.
-u, --unlock: Explicitly release the lock.
-w, --timeout <seconds>: Fail if the lock cannot be acquired within the specified timeout.
-o, --close: Close the file descriptor after the command finishes.
-c, --command <command>: Execute the specified command with lock held.

Common Parameters Cheatsheet

-x / --exclusive
Acquire an exclusive lock. Only one process can hold this lock at a time.
-s / --shared
Acquire a shared lock. Multiple processes can hold shared locks simultaneously.
-n / --nonblock
Do not wait if the lock is unavailable; exit immediately with failure.
-w / --timeout seconds
Wait up to the specified number of seconds for the lock.
-u / --unlock
Release the lock explicitly.
-c / --command command
Run the command while holding the lock.

Practical Examples

Example 1: Prevent Multiple Instances of a Script

This example prevents overlapping runs of a script by locking a file in /var/lock/:

    #!/bin/bash
    (
        flock -n 9 || { echo "Another instance is running"; exit 1; }

        # Critical section: commands that must not run concurrently
        echo "Running script safely..."
        sleep 10

    ) 9>/var/lock/mylockfile.lock

Explanation:

The subshell ( ... ) groups commands.
flock -n 9 tries to acquire an exclusive lock on file descriptor 9.
9>/var/lock/mylockfile.lock opens the lock file for writing as FD 9.
If the lock is unavailable, the script exits immediately with a message.
Otherwise, commands inside the subshell run safely under the lock.

Sample Output if Lock Acquired:

    Running script safely...

Sample Output if Lock Not Acquired:

    Another instance is running

Example 2: Using flock Inline in Shell

Run a single command with an exclusive lock on a lock file:

    flock /tmp/mylockfile -c "echo 'Locked command running'; sleep 5"

This acquires an exclusive lock on /tmp/mylockfile, runs the command, then releases the lock.

Example 3: Shared Lock for Concurrent Reads

    flock -s /tmp/mylockfile -c "cat /var/log/syslog | grep error"

Multiple processes can acquire shared locks simultaneously to safely read a file.

Example 4: Using flock with Cron Jobs

Add flock to a cron job to prevent overlapping runs:

    * * * * * /usr/bin/flock -n /var/lock/mycron.lock /usr/local/bin/mycronjob.sh

The -n option causes the job to skip if the lock is held by a previous run.

Example 5: Releasing Locks on Script Exit Using trap

    #!/bin/bash
    exec 200>/var/lock/myscript.lock

    flock -n 200 || { echo "Script already running"; exit 1; }

    trap 'flock -u 200; exit' INT TERM EXIT

    echo "Running critical section"
    sleep 30

    flock -u 200
    trap - INT TERM EXIT

This script:

Opens the lock file as FD 200.
Tries to acquire an exclusive lock.
Sets traps to release the lock on signals or exit.
Runs commands safely holding the lock.

Potential Problems and Pitfalls

Deadlocks: Occur when two or more processes wait indefinitely for locks held by each other. Avoid by ordering lock acquisition consistently and designing scripts carefully.
Stale Locks: If a process crashes without releasing its lock, the lock is automatically released because locks are tied to file descriptors and process lifetime. However, if using lock files improperly, stale lock files can remain.
Ignoring Locks: Advisory locks require all cooperating processes to respect them. If a process ignores the lock and accesses the file directly, corruption may occur.
Permission Issues: The user running flock must have appropriate permissions to create or write the lock file.
Lock File Location: Choose a directory like /var/lock or /tmp with proper permissions and cleanup policies.

Common Errors and Troubleshooting

flock: Resource temporarily unavailable
Occurs when using -n and the lock is held by another process. Handle by retrying or exiting gracefully.
Permission denied when creating lock file
Ensure the directory and lock file are writable by the user or run as appropriate user.
Deadlocks
Detect by analyzing process states with tools like ps or lsof, and avoid by design.
Lock not released after script exit
Usually indicates the process did not terminate properly; locks tied to file descriptors are released when the process exits.

Alternatives and Related Commands

lockfile: Another utility to create lock files with timeout and retries.
fcntl and lockf: System calls providing advisory locking at the programming level.
cron: Use with flock to prevent overlapping scheduled jobs.
trap: Useful to release locks on signals or exit.

Security Considerations

Lock files should be stored in secure directories with restricted permissions to avoid unauthorized access or lock stealing.
Avoid predictable lock file names to prevent malicious interference.
Ensure scripts running with elevated privileges use locks carefully to avoid privilege escalation risks.

Performance Considerations

flock uses lightweight kernel advisory locks, causing minimal overhead.
Excessive locking or long lock hold times can reduce concurrency and system responsiveness.
Use shared locks for read-only access to improve parallelism.