On 19 August 2013 08:48, Martin Panter <[email protected]> wrote: > > On 19/08/2013, Allan McRae <[email protected]> wrote: > > On 19/08/13 13:44, Jan Alexander Steffens wrote: > >> On Mon, Aug 19, 2013 at 5:39 AM, Allan McRae <[email protected]> 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
