NAME¶
dotlockfile - Utility to manage lockfiles
SYNOPSIS¶
/usr/bin/dotlockfile [
-l [
-r retries]
|
-u|
-t|
-c] [
-p] [
-m|
lockfile]
DESCRIPTION¶
dotlockfile is a command line utility to reliably create, test and remove
lockfiles. It creates lockfiles
reliably on local and NFS filesystems,
because the crucial steps of testing for a preexisting lockfile and creating
it are performed
atomically by a
single call to
link(2).
Manpage
lockfile_create(3) describes the used algorithm.
dotlockfile is installed with attribute
SETGID mail
and thus can also be used to lock and unlock mailboxes
even if the
mailspool directory is only writable by group mail.
The name
dotlockfile comes from the way mailboxes are locked for updates
on a lot of UNIX systems. A lockfile is created with the same filename as the
mailbox but with the string "
.lock" appended.
The names
dotlock and
lockfile were already taken - hence the name
dotlockfile :).
OPTIONS¶
- -l
- Create a lockfile if no preexisting valid lockfile is
found, else wait and retry according to option -r. This option is
the default.
A lockfile is treated as valid,
• if it holds the process-id of a running process,
• or if it does not hold any process-id and has been
touched less than 5 minutes ago (timestamp is younger than
5 minutes).
- -r retries
- The number of times dotlockfile retries to acquire
the lock if it failed the first time before giving up. The initial sleep
after failing to acquire the lock is 5 seconds. After each retry the
sleep intervall is increased incrementally by 5 seconds up to a
maximum sleep of 60 seconds between tries. The default number of
retries is 5. To try only once, use " -r 0". To try
indefinitely, use " -r -1".
- -u
- Remove a lockfile.
- -t
- Touch an existing lockfile (update the timestamp). Useful
for lockfiles on NFS filesystems. For lockfiles on local filesystems the
-p option is preferable.
- -c
- For debugging only: Check for the existence of a
valid lockfile.
Note: Testing for a preexisting lockfile and writing of the lockfile
must be done by the same " dotlockfile -l"
or " dotlockfile -m" command, else the lockfile creation
cannot be reliable.
- -p
- Write the process-id of the calling process into the
lockfile. Also when testing for an existing lockfile, check the contents
for the process-id of a running process to verify if the lockfile
is still valid. Obviously useful only for lockfiles on local
filesystems.
- -m
- Lock or unlock the current users mailbox. The path to the
mailbox is the default system mailspool directory (usually
/var/mail) with the username as gotten from getpwuid()
appended. If the environment variable $MAIL is set, that is used
instead. Then the string " .lock" is appended to get the
name of the actual lockfile.
- lockfile
- The lockfile to be created or removed. Must not be
specified, if the -m option is in effect.
RETURN VALUE¶
Zero on success, and non-zero on failure. For the
-c option, sucess means
that a valid lockfile is already present. When locking (the default, or with
the
-l option)
dotlockfile returns the same values as the
library function
lockfile_create(3). Unlocking a non-existant lockfile
is not an error.
NOTES¶
The lockfile is created exactly as named on the command line. The extension
"
.lock" is
not automatically appended.
This utility is a lot like the
lockfile(1) utility included with
procmail, and the
mutt_dotlock(1) utility included with
mutt. However the command-line arguments differ, and so does the return
status. It is believed, that
dotlockfile is the most flexible
implementation, since it automatically detects when it needs to use priviliges
to lock a mailbox, and does it safely.
The above mentioned
lockfile_create(3) manpage is present in the
liblockfile-dev package.
BUGS¶
None known.
SEE ALSO¶
lockfile_create(3),
maillock(3)
AUTHOR¶
Miquel van Smoorenburg, miquels@cistron.nl