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

[Allan McRae]

On 15/08/13 11:26, Dave Reisner wrote:
> On Aug 14, 2013 8:38 PM, "Mattias Andrée" <maandree at member.fsf.org> wrote:
>>
>> I understood that. But I did not know that pacman supports
>> BSD or Max OS X, nor that it was not portable. Just leaving
>> it out because of NFS seems silly, it is not up to the
>> program to account for all software that does not implement
>> expected standards.
> 
> Uhhh but it is. That's sort of the idea of software portability. And since
> when is file locking support anything close to standardized? It's
> incredibly OS and filesystem specific.
> 

So...  I know we have been over this several times, but is there no
reasonable solution here.

As far as I am concerned, OSX support is not a blocker here (as we kept
compile support of pacman to be nice, but some features of makepkg
already fail on OSX).   But, we need to support ELF based systems
(Linux, BSD, Hurd) as pacman is used on all these architectures.

flock() and probably fnctl() are out because NFS - and there are real
world use cases of this to be concerned about.

Does that leave us just the crappy file based locking?

I believe the cause of phantom lock files has been identified
(https://bugs.archlinux.org/task/35603) but I am unsure how to fix it.

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?

Any other ideas?

Allan