| SHLOCK(1) | General Commands Manual | SHLOCK(1) | 
shlock —
| shlock | [ -du] [-pPID]-flockfile | 
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.
#!/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.
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 | NetBSD 10.1 |