On Mon, Aug 19, 2013 at 10:58 AM, Martin Panter <[email protected]> wrote: > On 19 August 2013 08:48, Martin Panter <[email protected]> wrote: >> 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?
How about this? * Open lock file with O_RDWR | O_APPEND | O_CREAT and read. -> If file is empty, we can run. -> If file contains a non-existing PID and the current hostname on its last line, we can run. * If we can run, write new line containing current PID and hostname. * Rewind file and read again. Verify content is as expected. * Do database operation. * Remove lock file. I'm not sure how well it works over a network. Maybe one or more fsyncs can be introduced to ensure the appending and reading is synchronized with the server?
