From mboxrd@z Thu Jan  1 00:00:00 1970
From: Robin Roevens <robin.roevens@disroot.org>
To: development@lists.ipfire.org
Subject: Re: Stale pakfire lock-file causing pakfire to no longer work
Date: Thu, 15 Sep 2022 22:30:09 +0200
Message-ID: <fe5269ff7f9154c42f2b1f268ccc9f5c6dc8e981.camel@sicho.home>
In-Reply-To: <71fd83af-d174-30a1-d1f5-8ce0789fcbbf@ipfire.org>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============0787501051667907704=="
List-Id: <development.lists.ipfire.org>

--===============0787501051667907704==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

Hi Bernhard


Bernhard Bitsch schreef op do 15-09-2022 om 22:03 [+0200]:
> 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.


Maybe yet another approach (idea from here:
https://unix.stackexchange.com/a/594126 ) could be to actually check if
another process named 'pakfire' is active (using Proc::ProcessTable ?)
instead of using a lock(file). As pakfire is single-threaded, I think
this may just do the job?

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

Right, I missed that for a moment :-). 

Regards
Robin

> 
> Regards
> Bernhard
> 
> > Regards
> > Robin
> > 
> > > 
> > > Regards,
> > > Bernhard
> > > 
> > 
> 

-- 
Dit bericht is gescanned op virussen en andere gevaarlijke
inhoud door MailScanner en lijkt schoon te zijn.


--===============0787501051667907704==--