[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 August 2013 08:48, Martin Panter <vadmium+patch at gmail.com> wrote:
>
> 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.

Sorry I got my processes mixed up at the end. Here’s the steps:

* Lock file exists with process X which no longer exists
* Pacman process A starts and determines X does not exist
* Pacman process  B starts and determines X does not exist
* Process A removes the old lock file which referenced process X
* Process A creates a new lock file for itself (referencing process A now)
* How do you make sure B does not delete the new lock file A just created?

> > 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