[pacman-dev] Improving locking - Was: [PATCH] Use file locks (flock) to stop multiple pacman instances from running concurrently. This improves the current model by automatically removing locks held by programs has failed to remove the lock, for example at a crash, forced kill or power outage.

[Martin Panter]

On 19/08/2013, Allan McRae <allan at archlinux.org> wrote:
> On 19/08/13 13:44, Jan Alexander Steffens wrote:
>> On Mon, Aug 19, 2013 at 5:39 AM, Allan McRae <allan at archlinux.org> wrote:
>>> I stored the process ID in the lock file during creation many years ago.
>>>  Is there a portable way for us to determine if that process ID is still
>>> running and remove the lock file automatically if it is not?
>>
>> Try to kill the PID with signal 0 and remove it if it fails with ESRCH?

Pardon me if I don’t know enough details of Pacman’s locking, but this
sounds like a race condition, defeating the purpose of a lock. Even on
a single machine, what happens if two instances A and B have both
decided the old process does not exist, then instance A removes the
old lock, and creates a new valid lock for itself, just before
instance B also tries to remove the old lock? How do you stop A from
illegally removing B’s valid lock? Maybe you could have a two stage
thing or something but it’s getting a bit complex a.k.a. silly.

> After discussing on IRC with Jan, this whole approach has issues...
>
> It would be fine for the local db lock, but not for the sync db or
> package cache which might be accessed by multiple systems.
>
> Perhaps we'd require the pid and a machine identifier?   Of course, we
> could not clear leftover lock files from other machines, but we'd still
> fix the majority use case.
>
> Allan