The old logging statements in lockutils made for some confusing log
entries where it would appear a given lock was acquired multiple
times by different threads at the same time. See referenced bug
for details.
In order to alleviate that confusion, this change does a few things:
1) Adds an explicit "acquired" message inside the lock so it is
clear when the lock was actually acquired.
2) Moves the release message inside the semaphore so there's no
chance of it being logged out of order.
3) Removes the "Got semaphore" message and splits it into two
separate messages depending on whether the semaphore was found
in the weakref dictionary. Making it clear which code path
was followed should help with future debugging.
Change-Id: I0fbb473c60d48c9704597d9e3634402857861a66
Closes-Bug: 1367941
Adds a note to the lock_path help text explaining how to secure the
target directory. Also opens lock files in append mode so there is
no possibility of overwriting a file due to a malicious symlink.
Change-Id: I77b72b20088fe66b573c23bd1fd98376c2b0f168
After a lot of discussion[1], it was decided that this is the
safest way forward. In the future we can investigate alternative
locking methods, probably as opt-ins so we don't break any
existing consumers of these locks.
[1] http://lists.openstack.org/pipermail/openstack-dev/2014-August/043090.html
Change-Id: I49ff98abc395d3263d55aeff26081b462a8a294e
Partial-Bug: 1327946
