summaryrefslogtreecommitdiff
path: root/notes/lockfiles.mdwn
blob: 39eecda4cde724ea8a7b8c966449c7f60785bad9 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
# 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 or inbetween the
`mv lock stalelock` `unlink stalelock` `write lock` operations 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. The flock manpage describes how to do this.

## 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.