NAME
shlock —
create or verify a lock file
for shell scripts
SYNOPSIS
shlock |
[-du]
[-p PID]
-f lockfile |
DESCRIPTION
The
shlock command can create or verify a lock file on behalf
of a shell or other script program. When it attempts to create a lock file, if
one already exists,
shlock verifies that it is or is not
valid. If valid,
shlock will exit with a non-zero exit code.
If invalid,
shlock will remove the lock file, and create a
new one.
shlock uses the
link(2) system call to make the
final target lock file, which is an atomic operation (i.e. "dot
locking", so named for this mechanism's original use for locking system
mailboxes). It puts the process ID ("PID") from the command line
into the requested lock file.
shlock verifies that an extant lock file is still valid by
using
kill(2) with a zero signal
to check for the existence of the process that holds the lock.
The
-d option causes
shlock to be verbose
about what it is doing.
The
-f argument with
lockfile is always
required.
The
-p option with
PID is given when the
program is to create a lock file; when absent,
shlock will
simply check for the validity of the lock file.
The
-u option causes
shlock to read and
write the PID as a binary pid_t, instead of as ASCII, to be compatible with
the locks created by UUCP.
EXIT STATUS
A zero exit code indicates a valid lock file.
EXAMPLES
BOURNE SHELL
#!/bin/sh
lckfile=/tmp/foo.lock
if shlock -f ${lckfile} -p $$
then
# do what required the lock
rm ${lckfile}
else
echo Lock ${lckfile} already held by `cat ${lckfile}`
fi
C SHELL
#!/bin/csh -f
set lckfile=/tmp/foo.lock
shlock -f ${lckfile} -p $$
if ($status == 0) then
# do what required the lock
rm ${lckfile}
else
echo Lock ${lckfile} already held by `cat ${lckfile}`
endif
The examples assume that the file system where the lock file is to be created is
writable by the user, and has space available.
SEE ALSO
flock(1)
HISTORY
shlock was written for the first Network News Transfer
Protocol (NNTP) software distribution, released in March 1986. The algorithm
was suggested by Peter Honeyman, from work he did on HoneyDanBer UUCP.
AUTHORS
Erik E. Fair
<
fair@clock.org>
BUGS
Does not work on NFS or other network file system on different systems because
the disparate systems have disjoint PID spaces.
Cannot handle the case where a lock file was not deleted, the process that
created it has exited, and the system has created a new process with the same
PID as in the dead lock file. The lock file will appear to be valid even
though the process is unrelated to the one that created the lock in the first
place. Always remove your lock files after you're done.