Comment 1 for bug 1067336

On 16 October 2012 13:40, John A Meinel <email address hidden> wrote:
> Public bug reported:
>
> Maas takes a proper atomic lock during startup, but if the startup
> crashes, it does not properly release the lock file. (It only seems to
> release the lock when startup is successful.)
>
> The current workaround is to just manually rm /run/locks/maas*.lock
> That is a little dangerous because you might accidentally delete an active lock.

The lock is taken with setlock, which:

       ... opens fn for writing (creating it if it does not exist),
       obtains an exclusive lock on it, and runs child.

Where "runs" equals "execs".

This means that when setlock complains that there's still a lock held
that's because there *is* a process with an open file-handle to the
lock file. Use `fuser -v /run/lock/maas.*` to find out what.

> (It only seems to release the lock when startup is successful.)

This might be a bug; the lock is meant to be held the entire time that
the service is running.

With `make run` or `make services/.../@run`, setlock is used to invoke
the service's "run" script. When @start is used, setlock is used to
invoke the "supervise" process.