Last active
January 17, 2024 17:57
-
-
Save przemoc/571091 to your computer and use it in GitHub Desktop.
Lockable script
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
#!/bin/bash | |
# SPDX-License-Identifier: MIT | |
## Copyright (C) 2009 Przemyslaw Pawelczyk <przemoc@gmail.com> | |
## | |
## This script is licensed under the terms of the MIT license. | |
## https://opensource.org/licenses/MIT | |
# | |
# Lockable script boilerplate | |
### HEADER ### | |
LOCKFILE="/var/lock/`basename $0`" | |
LOCKFD=99 | |
# PRIVATE | |
_lock() { flock -$1 $LOCKFD; } | |
_no_more_locking() { _lock u; _lock xn && rm -f $LOCKFILE; } | |
_prepare_locking() { eval "exec $LOCKFD>\"$LOCKFILE\""; trap _no_more_locking EXIT; } | |
# ON START | |
_prepare_locking | |
# PUBLIC | |
exlock_now() { _lock xn; } # obtain an exclusive lock immediately or fail | |
exlock() { _lock x; } # obtain an exclusive lock | |
shlock() { _lock s; } # obtain a shared lock | |
unlock() { _lock u; } # drop a lock | |
### BEGIN OF SCRIPT ### | |
# Simplest example is avoiding running multiple instances of script. | |
exlock_now || exit 1 | |
# Remember! Lock file is removed when one of the scripts exits and it is | |
# the only script holding the lock or lock is not acquired at all. |
An ugly test - if I kill -9 pid-of-my-script
, then it doesn't have a chance to remove the lock.
An ugly test - if I
kill -9 pid-of-my-script
, then it doesn't have a chance to remove the lock.
This will always be true. kill -9 is "non-catchable, non-ignorable kill", the OS won't let you do anything when you get one, it's the equivalent of pulling taking an axe to the power supply. It's why you should escalate to kill -9
when trying to fix something, not start there.
This is beautiful. Thank you.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi,
I was evaluating this solution, the code works in the common case, but IMHO it has some formal issues.
AFAIU synchronization via flock is performed on the actual file on the filesystem (or in memory), not on the file name nor on the file descriptor, these latter are just convenience mechanisms to access the file end hence the lock.
Some example to verify that:
LOCKFD=$(( (RANDOM % 100) + 1))
Conversely, if the same file name refers to different files at two different points in time, locking would not work as desired.
For example:
the two file descriptors refer to different files in memory, even if they were opened with the same file name.
Considering that, I think the proposed solution leaves a window between
_prepare_locking()
and_lock()
which can be problematic.If for some reason
$LOCKFILE
gets deleted by some other entity when the first invocation is between_prepare_locking()
and_lock()
, a second invocation would fail to synchronize, because this second_prepare_locking()
would create a new file (even when using the same name), so it would execute regardless of the first invocation.To reduce the window to the minimum
_lock
and_prepare_lock
could be merged into one function, there will be a little extra work if the script locks and unlocks multiple times but it will be more robust.Finally, about
_no_more_locking()
consider adding a comment to explain that it is like that to supportexlock
orshlock
; in case onlyexlock_now()
is required the function would not be needed and just atrap "rm -f \"$LOCKFILE\";"
would suffice since the lock will be released automatically when the process exits and the file is closed.FWIW I ended up using the
mkdir
approach (http://wiki.bash-hackers.org/howto/mutex) in my scripts which looks simpler and more robust.Sorry for the long post.
Ciao,
Antonio