lockfile - Online in the Cloud

PROGRAM:

NAME

lockfile - conditional semaphore-file creator

SYNOPSIS

lockfile -sleeptime | -r retries |
-l locktimeout | -s suspend | -! | -ml | -mu | filename ...

DESCRIPTION

lockfile can be used to create one or more semaphore files. If lockfile can't create all
the specified files (in the specified order), it waits sleeptime (defaults to 8) seconds
and retries the last file that didn't succeed. You can specify the number of retries to
do until failure is returned. If the number of retries is -1 (default, i.e., -r-1)
lockfile will retry forever.

If the number of retries expires before all files have been created, lockfile returns
failure and removes all the files it created up till that point.

Using lockfile as the condition of a loop in a shell script can be done easily by using
the -! flag to invert the exit status. To prevent infinite loops, failures for any
reason other than the lockfile already existing are not inverted to success but rather are
still returned as failures.

All flags can be specified anywhere on the command line, they will be processed when
encountered. The command line is simply parsed from left to right.

All files created by lockfile will be read-only, and therefore will have to be removed
with rm -f.

If you specify a locktimeout then a lockfile will be removed by force after locktimeout
seconds have passed since the lockfile was last modified/created (most likely by some
other program that unexpectedly died a long time ago, and hence could not clean up any
leftover lockfiles). Lockfile is clock skew immune. After a lockfile has been removed by
force, a suspension of suspend seconds (defaults to 16) is taken into account, in order to
prevent the inadvertent immediate removal of any newly created lockfile by another program
(compare SUSPEND in procmail(1)).

Mailbox locks
If the permissions on the system mail spool directory allow it, or if lockfile is suitably
setgid, it will be able to lock and unlock your system mailbox by using the options -ml
and -mu respectively.

EXAMPLES

Suppose you want to make sure that access to the file "important" is serialised, i.e., no
more than one program or shell script should be allowed to access it. For simplicity's
sake, let's suppose that it is a shell script. In this case you could solve it like this:
...
lockfile important.lock
...
access_"important"_to_your_hearts_content
...
rm -f important.lock
...
Now if all the scripts that access "important" follow this guideline, you will be assured
that at most one script will be executing between the `lockfile' and the `rm' commands.

ENVIRONMENT

LOGNAME used as a hint to determine the invoker's loginname

Use lockfile online using onworks.net services