How to use the Flock Control program's asynchronous execution _unix Linux in Linux

Recently I often need to SSH to several computers at the same time to do a lot of work that needs to wait and can be done at the same time. For example:

1. Let the remote computer update the kit at the same time

2. Simultaneous transfer of small files to the remote computer (most of the time in SSH certification)

However, the following actions need to be confirmed after the completion of the work can continue.

That's what I used to do:

# The work ahead
update_pkg_on_machine_1
update_pkg_on_machine_2
update_pkg_on_machine_3
# ... The work behind

This will ensure that the work is done at the same time, but it is very slow ...

Another possible approach would be to:

# The work ahead
Update_pkg_on_machine_1 &
update_pkg_on_machine_2 &
Update_pkg_on_machine_3 & Sleep
# ... The work behind

Although this can work at the same time, but if the work is not finished in 10 seconds, the next work may be wrong.

And the work to be done in a few seconds, in fact, it is difficult to grasp.

Use flock to manage work status

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

Official description of Flock

NAME flock-manage locks from Shell scripts Synopsis flock [-sxon] [-w timeout] lockfile [-c] command ... flock [ -sxon] [-w timeout] lockdir [-c] command ... flock [-sxun] [-w timeout] FD DESCRIPTION This utility manages flock (2) L

  Ocks from within shell scripts or the command line. The second forms wraps the lock around the executing a command, in a manner similar to SU (1) or NEWGRP (1). It locks a specified file or directory, which is created (assuming appropriate permissions), if it does not already ex

  Ist. The third form is convenient inside shell scripts, and is usually used the 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 being created if it does not already, exist, write however is re quired; Using < requires that the file already exists but only read permisSion is required.

By default, if the lock cannot to immediately acquired, Flock waits until the lock is available.

  Options-s,--shared obtain a shared lock, sometimes called a read lock. -X, E,--exclusive obtain an exclusive lock, sometimes called a write lock.

  This is the default. -U,--unlock Drop a lock. This isn't usually required, since a lock is automatically dropped when the file is closed. However, it may is required in special cases, for example if the enclosed command group may have forked a Backgrou

  ND process which should not is holding the lock.

  -N,--NB,--nonblock Fail (with a exit code of 1) rather than wait if the lock cannot is immediately acquired. -W,--wait,--timeout seconds Fail (with a exit code of 1) If the lock cannot be acquired within seconds second

  S. Decimal fractional values are allowed. -O,--close close the ' file descriptor on which ' lock is held before executing commanThe D. This is useful if command spawns a child process which should not being hold ing the lock.

  -C,--command command pass a single command to the shell with-c.

-H,--help Print a help message.

AUTHOR written by H. Peter Anvin  

Key notes

Through flock, the program will first attempt to obtain a lock (usually representative of a file) after the ownership, execution will hold the lock ownership, and after the end of the release of ownership.

For example, if we write a shell script underneath the $HOME:

#! /bin/bash Sleep
Date

Store as test.sh and open Execute permissions (chmod test.sh)

At this point, if we open two shells, and we execute at about the same time:

Flock/tmp/demo.lock ~/test.sh

What will happen then?

The user should see two shell stops, one waits 10 seconds to print out time, one after 10 seconds to print out time:

A

wush@router:~$ Flock/tmp/demo.lock./test.sh

B

wush@router:~$ Flock/tmp/demo.lock./test.sh

Where a program first grabs /tmp/demo.lock the ownership and then executes it test.sh . and the B program waits until the end of a procedure (a return /tmp/demo.lock of ownership), only to get /tmp/demo.lock the ownership. So the B program is naturally slower than a program 10 seconds.

Parameters of Flock

In addition to the default behavior, we can adjust the behavior of flock through parameters. The main difference with default behavior is that when the Lock_path is not available, the next action will be different.

1.flock-n lock_path XXX: When the ownership is not available, directly suspend the program, do not execute xxx.

2.flock-s lock_path XXX: lock_path as a shared lock and can be owned by multiple programs. So everyone can do it right away and have lock_path at the same time.

3.flock-x lock_path XXX: Lock_path as a exclusive lock, and can only be owned by a program.

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

Solve the problem in the introduction

So through the combination of flock, I can do several jobs at the same time, and wait until they are finished and then continue to do the following work:

# The work ahead
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!"
# ... The work behind

The key is that flock -x lock_path xxx they cannot coexist because of shared and exclusive mutually exclusive relationships. So it will wait until the above work is over (return Lock_path ownership) before it is executed.

The above is the use of Flock Command control program on Linux the full content of asynchronous execution, the need for friends can refer to learning.