diff options
| -rw-r--r-- | notes/lockfiles.mdwn | 40 |
1 files changed, 40 insertions, 0 deletions
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. |