For example:

https://github.com/stackforge/tooz/commit/f3e11e40f9871f8328e107bf1390c532fbe3a54b

On Friday, August 8, 2014, Joshua Harlow <email address hidden> wrote:

> Understood, I was thinking also of the issue that more than just sevices
> use the oslo incubator and copy and paste code from it.
>
> I'm pretty sure stackforge projects are and others (taskflow is to,
> although I haven't synced this over due to this bug, tooz just copied
> lockutils over recently... so it now provides an interface to a buggy
> feature...)
>
> Looking forward to the fixed version on oslo.concurreny (although someone
> IMHO should tell people to stop using the buggy lockutils or only use it
> with the services module...)
>
> On Thursday, August 7, 2014, Yuriy Taraday <<email address hidden>
> <javascript:_e(%7B%7D,'cvml','<email address hidden>');>> wrote:
>
>> I guess operators don't usually kill OpenStack daemons with brutal
>> signals. This issue shouldn't appear with simple SIGINT or SIGTERM as
>> they're handled by openstack.common.service and cause graceful stop and
>> all locks should be released while appropriate context managers exit.
>> This problem would however appear if someone tries to kill process the
>> second time with one of these signals since handler is set to default
>> after the first signal.
>>
>> Anyway, SysV signals are better in this regard. Thanks to Philip,
>> sysv_ipc is already up on PyPI and so my fix have one less barrier on
>> the way to master. The fix might land to oslo.concurrency though, given
>> lockutils are in process of graduation there.
>>
>> --
>> You received this bug notification because you are subscribed to the bug
>> report.
>> https://bugs.launchpad.net/bugs/1327946
>>
>> Title:
>>   PosixLock not resistant to program termination
>>
>> Status in Oslo - a Library of Common OpenStack Code:
>>   In Progress
>>
>> Bug description:
>>   If a program is terminated via ctrl-c or other signal and it has
>>   acquired locks using the posix_ipc sempahore those sempahores are
>>   never released (unlike the filelock which does release automatically
>>   on program termination). This can be easily seen by trying the
>>   following in a shell (see below). You can come back after minutes and
>>   hours and try to acquire the abandoned semaphore and still be unable
>>   to (it's still apparently busy), perhaps there is a automatic timeout
>>   that needs to be provided? I can imagine that if people do upgrades of
>>   a service (using for example `service nova-api stop`) using this lock
>>   and the program is currently locked that they would have to have some
>>   kind of sempahore cleaning script to even restart that application
>>   (which seems bad).
>>
>>   Python 2.7.6 (default, Mar 22 2014, 22:59:56)
>>   [GCC 4.8.2] on linux2
>>   Type "help", "copyright", "credits" or "license" for more information.
>>   >>> from openstack.common import lockutils
>>   >>> import os
>>   >>> os.getpid()
>>   16123
>>   >>> lockutils.InterProcessLock("testing")
>>   <openstack.common.lockutils._PosixLock object at 0x7f8bb4a8e210>
>>   >>> a = lockutils.InterProcessLock("testing")
>>   >>> a.acquire()
>>   <openstack.common.lockutils._PosixLock object at 0x7f8bb30e7ad0>
>>   >>> exit()
>>   (.dev)josh@lappy:~/Dev/oslo-incubator$ python
>>   Python 2.7.6 (default, Mar 22 2014, 22:59:56)
>>   [GCC 4.8.2] on linux2
>>   Type "help", "copyright", "credits" or "license" for more information.
>>   >>> from openstack.common import lockutils
>>   >>> import os
>>   >>> os.getpid()
>>   16128
>>   >>> a = lockutils.InterProcessLock("testing")
>>   >>> a.acquire(timeout=5)
>>   Traceback (most recent call last):
>>     File "<stdin>", line 1, in <module>
>>     File "openstack/common/lockutils.py", line 168, in acquire
>>       self.semaphore.acquire(timeout)
>>   posix_ipc.BusyError: Semaphore is busy
>>   ....
>>
>> To manage notifications about this bug go to:
>> https://bugs.launchpad.net/oslo/+bug/1327946/+subscriptions
>>
>
>
> --
> --
> facebook.com/jshharlow <http://www.facebook.com/jshharlow>
> flickr.com/jshharlow
> YIM: jshharlow
>
>

-- 
--
facebook.com/jshharlow <http://www.facebook.com/jshharlow>
flickr.com/jshharlow
YIM: jshharlow