* Cleanup lockutils logging by showing lock name and function in
same line. The enables easier parsing of information related to lock
acquisition from logs.
* Logs time a thread spent waiting on locks, as well as time spent
holding locks. This will make it easier to debug suboptimal locking.
Change-Id: Ic310d84eb1ed75cc1c21c3d7861b4a3927ebaf23
To be better able to identify when and where are file lock
breaks when release occurs it's useful to distingush the
different steps of release and independently log them as
unique steps.
Change-Id: I3b605994ca7673e5c97e73821d2ea777117f5f09
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
