SHLOCK(1) | General Commands Manual | SHLOCK(1) |
shlock
— create or
verify a lock file for shell scripts
shlock |
[-du ] [-p
PID] -f
lockfile |
NOTE:
The shlock
command is deprecated, and
lockf(1) should be used instead.
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.
A zero exit code indicates a valid lock file.
#!/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
#!/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.
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.
Erik E. Fair <fair@clock.org>
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.
November 2, 2012 | macOS 14.6 |