Using the flock command on Linux to control the asynchronous execution of programs

  
 

Recently I often need to do ssh to a number of computers
to do a lot of work that needs to be done and can be done at the same time. For example: 1. Let the remote computer update the kit at the same time 2. Send the small file to the remote computer at the same time (most of the time is ssh authentication)

However, the subsequent actions need to confirm the above work. keep going.

I used to do this in the past: #前工作update_pkg_on_machine_1update_pkg_on_machine_2update_pkg_on_machine_3# ... The work behind

This ensures that the work is done at the same time, but it is very slow …

Another possible method is: #前工作update_pkg_on_machine_1 &update_pkg_on_machine_2 &update_pkg_on_machine_3 &sleep 10# ... The work behind

This can work at the same time, but if it is 10 seconds The work has not been completed yet, and the next work may be wrong.

It’s hard to master how many seconds a job is done.

Using flock to manage work status

I used to learn the mutex when I was working on the operating system, and flock is a mutex that can be used on the shell.

The official description of flock

Let's take a look at the description of flock on ubuntu lucid: NAMEflock - Manage locks from shell scripts

SYNOPSISflock [-sxon] [-w timeout Lockfile [-c] command...

flock [-sxon] [-w timeout] lockdir [-c] command...

flock [-sxun] [-w timeout fdDESCRIPTIONThis utility manages flock(2) locks from within shell scripts or thecommand line.

The first and second forms wraps the lock around the executing acommand, in a manner similar to su(1) or newgrp(1) It locks aspecified file or directory, which is created (assuming appropriatepermissions), if it does not already exist.

The third form is convenient inside shell scripts, and is usually usedthe following manner:

(flock -s 200# ... commands executed under lock ...) 200>/var/lock/mylockfile

The mode used to open the file doesn’t matter to flock; using > or >>allows the lockfile to be created if it does not already exist,however, write permission is required; Using < requires that the filealready exists but only read permission is required.

By default, if the lock cannot be immediately acquired, flock waitsuntil the lock is available.

OPTIONS-s, - -sharedObtain a shared lock, sometimes called a read lock.

-x, -e, --exclusiveObtain an exclusive lock, sometimes called a write lock. Thisis the default.

-u, --unlockDrop a lock. This is usually not required, since a lock isautomatically dropped when the file is closed. However, it maybe required in special cases, for example if the enclosedcommand group may have forked a background process which shouldnot be holding the lock .

-n, --nb, --nonblockFail (with an exit code of 1) rather than wait if the lockcannot be immediately acquired.

-w, --wait, -- Timeout secondsFail (with an exit code of 1) if the lock cannot be acquiredwithin seconds seconds. Decimal fractional values ​​are allowed.

-o, --closeClose the file descriptor on which the lock is held before Execution command. This is useful if command spawns a childprocess which should not be hold ing the lock.

-c, --command commandPass a single command to the shell with -c.

- h, --helpPrint a help message.

AUTHORWritten by H. Peter Anvin <[email protected]>.

COPYRIGHTCopyright © 2003-2006 H. Peter Anvin.This is free Software; see the source for copying conditions. There is no warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULARPURPOSE.

SEE ALSOflock(2)

AVAILABILITYThe flock command is part of the util-linux -ng package and is availablefrom ftp://ftp.kernel.org/pub/linux/utils/util-linux-ng/.

Keynotes

With flock, the program will first It is only executed after trying to acquire the ownership of a lock (usually representing a file). The execution will hold the ownership of the lock and release the ownership after the end.

Programmer efficient development tool: programming cup programmer efficient development tool: programming cup

For example, if we write a shell script under $HOME: #! /bin/bashsleep 10date

Save to test.sh and open execute permission (chmod 700 test.sh)

At this point if we open two shells and execute them at the same time: flock /tmp/demo.lock ~/test.sh

What happens at this time?

Users should see both shells stop, one will wait 10 seconds to print out the time, and one after 10 seconds to print out the time:

A

wush@router:~$ flock /tmp/demo.lock ./test.shSat Jan 4 00:55:24 CST 2014B

wush@router:~$ flock /tmp/demo.lock ./test .shSat Jan 4 00:55:34 CST 2014

The A program first grabs the ownership of /tmp/demo.lock and then executes test.sh. The B program waits until the end of the A program (A returns the ownership of /tmp/demo.lock), and then gets the ownership of /tmp/demo.lock. So the B program is naturally 10 seconds slower than the A program.

Flock parameters

In addition to the default behavior, we can adjust the behavior of the flock through parameters. The main difference from the default behavior is that when the ownership of lock_path is not available, the next action will be different. 1.flock -n lock_path xxx: When the ownership is not available, the program is aborted directly, and xxx is not executed. 2.flock -s lock_path xxx: Treats lock_path as a shared lock and can be owned by multiple programs. So everyone can execute it right away, and at the same time have lock_path3.flock -x lock_path xxx: treat lock_path as an exclusive lock and can only be owned by one program.

Note: A lock_path cannot be shared and exclusive at the same time!

Resolve problems in the introduction

So by combining flock, I can perform several tasks at the same time, and wait until they are finished before continuing with the next work: #前工作flock - s lock_path update_pkg_on_machine_1 &flock -s lock_path update_pkg_on_machine_2 &flock -s lock_path update_pkg_on_machine_3 &flock -x lock_path echo "all done!"# ... Behind work

The key lies in flock -x lock_path Xxx will not coexist because of the mutually exclusive relationship between shared and exclusive. Therefore, it will wait until the above work ends (returning the ownership of lock_path).

Copyright © Windows knowledge All Rights Reserved