From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bernhard Bitsch To: development@lists.ipfire.org Subject: Re: Stale pakfire lock-file causing pakfire to no longer work Date: Thu, 15 Sep 2022 22:03:09 +0200 Message-ID: <71fd83af-d174-30a1-d1f5-8ce0789fcbbf@ipfire.org> In-Reply-To: <44a87a6c1fdba4c724e15a22467d2b5b4224577a.camel@sicho.home> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1530876889813358885==" List-Id: --===============1530876889813358885== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Hi Robin, Am 15.09.2022 um 21:43 schrieb Robin Roevens: > Hi Bernhard > > Bernhard Bitsch schreef op do 15-09-2022 om 13:48 [+0200]: >> Hi all, >> >> as an 'old real time programmer' this reminds me deeply at >> Dijkstra/Hoare's "Dining philosophers problem". >> >> The check for presence of the lockfile and the generation of it are >> not >> 'atomic'. Means two programs can run in parallel. > Indeed.. > In a shell script, a more atomic approach would be instead of using a > lockfile, a lock-directory: > 'mkdir' creates a directory only if it not already exists and if it > does already exist, it will return an exit code. So here we have both > checking and generating in one atomic operation. > This is better explained here: > https://wiki.bash-hackers.org/howto/mutex > > Not sure if this can be translated to Perl in an atomic way.. > I did find this perl code snippet however: > --- > use strict; > use warnings; > use Fcntl ':flock'; > > flock(DATA, LOCK_EX|LOCK_NB) or die "There can be only one! [$0]"; > > > # mandatory line, flocking depends on DATA file handle > __DATA__ > --- > Which could be a possible solution, I think. > Looks promising. Will look into this. > I also found this, which seems quiet promising: > https://metacpan.org/pod/Script::Singleton > to perform locking by using shared memory. > >> >> I'll investigate this further. But the deletion of the lock should >> happen anyways, as far I've seen till now. > True, it should be deleted always and as said before, I could not > reproduce this manually .. but my Zabbix agent seems to be able to > trigger this problem at least once every 24h on my IPFire mini > appliance, only by executing pakfire every 10 minutes. That is why I'm > suspecting the abnormal termination of pakfire, leaving the lockfile in > place, is actually caused by sudo. > > On the other hand.. this can also happen when pakfire is running and > suddenly the power is cut.. then the lockfile will still be present > when the machine is back up.. So I think, if we stay with the lockfile, > we at least need some check for a stale lockfile, like checking if the > process that created the lockfile still exists or not and removing it > if not. > Because the lockfile is located in /tmp, I don't think it survives a reboot. Regards Bernhard > Regards > Robin > >> >> Regards, >> Bernhard >> > --===============1530876889813358885==--