From 982e7ea8985b306ebb019db6ec21b8cce1184c1f Mon Sep 17 00:00:00 2001 From: Joe Rayhawk Date: Sun, 10 Jan 2010 22:52:54 -0800 Subject: Notes: lockfile: new --- notes/lockfiles.mdwn | 40 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 40 insertions(+) create mode 100644 notes/lockfiles.mdwn (limited to 'notes') diff --git a/notes/lockfiles.mdwn b/notes/lockfiles.mdwn new file mode 100644 index 0000000..197bba7 --- /dev/null +++ b/notes/lockfiles.mdwn @@ -0,0 +1,40 @@ +# script shell /bin/sh /bin/bash mutex/semaphore/lock + +## Random example shell scripts out on the web + +All locks need a read/compare/delete/write transaction that is not practical +with the shell alone. Imagine a `sleep` statement in front of the +`rm stalelock` operation and what that would do to other processes. + +Process name comparison won't work very well as scripts aren't always executed +under their own name or even as their own process. For example, +`. /path/to/script` is an accidental means of execution that wouldn't show up +in a process table. + +## procmail's lockfile + +Does not deal with stale locks. At all. + +## lockfile-progs + +`lockfile-create --use-pid --retry 0 /tmp/lockfile-create-test` will always +succeed: not transactional. + +## flock + +Cumbersome, but doable. You'd probably want to wrap all the exclusive bits in a +subshell. + +## moreutils' lckdo + +Probably optimal. Check for parent process ID and re-execute. + +`if ! grep -q lckdo /proc/$PPID/cmdline; then + exec lckdo /tmp/lckdotest $0 "$@" +fi` + +## chiark-utils-bin's with-lock-ex + +Cannot check parent ID since it is already using exec. Would need to find if +the lockfile has been inherited as an fd and re-execute, which is more painful +than what is needed for lckdo. -- cgit v1.2.3