Attempts to lock pid files should be non-blocking

[Ryan Moe]

When another process already has an exclusive lock on a pid file subsequent attempts to lock will block indefinitely. This is problematic when this happens in e.g the ns-metadata-proxy. When the ns-metadata-proxy blocks on locking its pid file the l3-agent will not be able to bring up any of the router's interfaces.

[Kevin Benton (kevinbenton)]

This is normally handled with the use of greenthreads. When one thread tries to grab a lock and it is already taken, it will yield to another coroutines. Do you have a reference to the specific location that is blocking?

[Ryan Moe (rmoe)]

This is where I encountered the issue: https://github.com/openstack/neutron/blob/master/neutron/agent/linux/daemon.py#L40. If another process holds a lock on pidfile the fcntl.flock call will never return. I've also proposed a fix here: https://review.openstack.org/#/c/91890/

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/91890
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=797fa55fef2e28cce9dd8f06009217e57bb31e91
Submitter: Jenkins
Branch: master

commit 797fa55fef2e28cce9dd8f06009217e57bb31e91
Author: Ryan Moe <email address hidden>
Date: Fri May 2 13:08:45 2014 -0700

    Make pid file locking non-blocking

    fcntl.flock will block indefinitely if another process holds an exclusive
    lock. A non-blocking flock operation will raise an error when a lock already
    exists so we can fail immediately.

    Closes-bug: 1315507
    Change-Id: Icf97b1f8643157719b3d28ac2c0c1576a5069697