> -----Original Message----- > From: Marta Rybczynska <[email protected]> > Sent: Monday, November 10, 2025 16:00 > To: Richard Purdie <[email protected]> > Cc: [email protected]; [email protected]; > [email protected]; Marko, Peter (FT D EU SK BFS1) > <[email protected]> > Subject: Re: [OE-core] [PATCH 5/5] cve-update: Keep mtime stamp in the > database itself > > > > On Mon, Nov 10, 2025 at 3:16 PM Richard Purdie > <[email protected] > <mailto:[email protected]> > > wrote: > > > On Mon, 2025-11-03 at 14:31 +0000, Niko Mauno via > lists.openembedded.org <http://lists.openembedded.org> wrote: > > This should help to avoid problems that will occur if the modification > > time of database file itself is altered e.g. by unassociated > > process(es) on the file system which hosts the database file. > > > > Since this change updates the database structure by adding a new > table, > > bump the 'minor' version number in database file names to enforce full > > database fetch. This should also iron out e.g. situation where the > > database might have inconspicuously omitted entries due to way in > which > > the mtime of database file itself was relied upon. > > > > Signed-off-by: Niko Mauno <[email protected] > <mailto:[email protected]> > > > --- > > meta/classes/cve-check.bbclass | 2 +- > > .../recipes-core/meta/cve-update-db-native.bb <http://cve-update-db- > native.bb> | 3 + > > meta/recipes-core/meta/cve-update-native.inc | 59 > ++++++++++++------- > > .../meta/cve-update-nvd2-native.bb <http://cve-update-nvd2-native.bb> > | 3 + > > 4 files changed, 46 insertions(+), 21 deletions(-) > > I am a bit worried about this since it takes what is a simple mtime > comparison and means that to check the database you now have to lock > and open it which is comparatively expensive. > > What kind of "unassociated processes" are updating the mtime? > > > > > I second Richard here. If we would really want to keep the date somewhere else > than the file > timestamp, we could create a simple file that stores it, what is way simpler > and > doesn't require > to open the database just to see if you want to update it. > > I second Richard's question: in what kind of a situation have you seen an > issue?
The issue is on Yocto AB. It has not updated statistics for more than 5 months now. Looking at the logs, something is updating mtime very frequently... I don't know the AB infrastructure, but it looks like there is some filesystem crawler, maybe backup of sync process. Or the nfs mount is plain broken there? Example is here: https://valkyrie.yocto.io/pub/non-release/20251109-43/testresults/metrics/db-update/ NOTE: Current time: Sun Nov 9 07:17:52 2025; DB time: Sun Nov 9 07:14:51 2025 NOTE: Current time: Sun Nov 9 07:19:22 2025; DB time: Sun Nov 9 07:18:14 2025 2 jobs are 90 seconds from each other, but something managed to change the timestamp in between and only 3.5 minutes after last change! Peter > > Kind regards, > Marta
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#226125): https://lists.openembedded.org/g/openembedded-core/message/226125 Mute This Topic: https://lists.openembedded.org/mt/116098343/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
