28.11.2011 13:09, Ulrich Windl wrote:
> Hi!
>
I posted one more implementation in
http://www.mail-archive.com/[email protected]/msg19760.html as
a part of bigger code snippet.
It just uses -C shell option to create lock files (exists at least in
bash and dash).
> Here is a locking sample (potential replacement functions) that
> seems
> to work: Just start the script more than once as a background process
> and watch the output
> -----------snip locks.sh --------------------
> MASTERLOCKFILE=/tmp/blabla
>
> lock() {
> (flock -e 123 &&
> if [ -e "$1" ]; then
> if ! kill -0 $(<"$1") 2>&1 > /dev/null; then
> # stale lock
> echo $$ > "$1"
> else
> false
> fi
> else
> echo $$ > "$1"
> fi) 123> $MASTERLOCKFILE
> }
>
> unlock() {
> (flock -e 124 && test -e "$1" && rm "$1") 124> $MASTERLOCKFILE
> }
>
> # "application"
> while true
> do
> while ! lock /tmp/foobar; do
> echo "waiting for lock $$"
> sleep 0.2
> done
> echo "lock OK $$"
> sleep 0.1
> if unlock /tmp/foobar; then
> echo "unlock OK $$"
> else
> echo "unlock FAIL $$"
> fi
> sleep 0.1
> done
> ---------------------snip--------------------
>
> Regards,
> Ulrich
>
>
>>>> "Ulrich Windl" <[email protected]> schrieb am 28.11.2011 um
> 10:07 in Nachricht <[email protected]>:
>> Hi!
>>
>> I was requested to work around a kernel bug by adding locks to my RA.
>> Reading the docs I found that ist supposed to be done via
>>
>> ocf_take_lock $LOCKFILE
>> and
>> ocf_release_lock_on_exit $LOCKFILE
>>
>> Out of curiosity I inspected the implementation in SLES11 SP1. To me the
>> functions are improperly implemented (unless I'm wrong) because:
>>
>> 1) you can have only one lock per RA, no matter what $LOCKFILE you provide.
>> This is because actually not the $LOCKFILE is the lock, but the process ID
>> of
>> the shell
>>
>> 2) the implementation does not guarantee mutual exclusion:
>>
>> ocf_pidfile_status() is used to query for an unowned lock. ocf_take_lock()
>> in turn waits until either the specified lockfile does not exist, or the PID
>> in the lockfile vanished.
>>
>> Then the PID of the RA's shell is written into the lockfile. As can be seen,
>> multiple processes can do that if no lock exists.
>>
>> If you had parallel execution of RAs before, you'll have parallel execution
>> even with those "locks".
>>
>> Finally you can only release the lock using ocf_release_lock_on_exit().
>> Unfortunately that function will only release tha last lock passed to that
>> function as "trap" does not accumulate the commends you give to it.
>>
>> Maybe an approach using flock(1) instead might be better (untested, just
>> from reading the docs):
>>
>> lock() {
>> (flock -e 123; test -e $LOCKFILE || touch $LOCKFILE) 123> $MASTERLOCKFILE
>> }
>>
>> unlock() {
>> (flock -e 124; test -e $LOCKFILE && rm $LOCKFILE) 124> $MASTERLOCKFILE
>> }
>>
>> Regards,
>> Ulrich
>>
>>
>> _______________________________________________
>> Linux-HA mailing list
>> [email protected]
>> http://lists.linux-ha.org/mailman/listinfo/linux-ha
>> See also: http://linux-ha.org/ReportingProblems
>>
>
>
>
>
> _______________________________________________
> Linux-HA mailing list
> [email protected]
> http://lists.linux-ha.org/mailman/listinfo/linux-ha
> See also: http://linux-ha.org/ReportingProblems
_______________________________________________
Linux-HA mailing list
[email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems
