Notes: lockfile: new

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.