NAME

run1 - Run a program once at a time

SYNOPSIS

run1 [ -d dir ] [ -l label ] [ -w sec ] [ -k sec ] program [ args ]

DESCRIPTION

This program is useful for keeping multiple copies of a program from running concurrently.

OPTIONS

-d directory
Save lock/pid files in directory instead of the default (~/.locks).

-l label
Use label as the lock/pid file name. The default is the name of the program being executed.

-w seconds
Print a warning to stderr if the process with the lock has been running for more than seconds seconds. The default is 86400 seconds, or one day. Specifying 0 seconds disables warning messages.

-k seconds
Kill the process with the lock if it has been running for more than seconds seconds. The default is 0, which disables this feature.

-s
Try to get a shared lock on the lock file. This is useful for nesting calls to run1. Say you have two scripts that can operate independently, and another script that does the equivalent of the first two, in addition to whatever other work it might do. For example, a script that mirrors a linux distribution ftp site. One syncs only updates, the second syncs only the distribution, and a third syncs the whole tree. You might invoke them like this: 
    run1 -s -l mirror run1 mirror-updates
    run1 -s -l mirror run1 mirror-dist
    run1 -l mirror mirror-all

Since mirror-updates and mirror-dist get a shared lock on ``mirror'', they'll keep mirror-all from running, but they'll run just fine individually. While mirror-all is running, neither mirror-updates or mirror-dist will run.

Note that currently -w and -k are ignored when using shared locks. (This may or may not change at some point in the future.)

NOTES

Please note that this script will only work reliably when the lock directory is on a filesystem (and operating system) where you can rely on open(2) with O_EXCL and flock(2) working properly. In other words, don't point the lock directory to a network filesystem (especially NFS). Use -d /some/local/dir.

SEE ALSO

lockfile(1)

BUGS

The limitations of the locking system (see NOTES above) could be construed as bugs.

AUTHOR

Steven Pritchard <steve@silug.org>