prometheus-community / node-exporter-textfile-collector-scripts

Scripts for node-exporter's textfile collector
Apache License 2.0
488 stars 185 forks source link

apt cache age computed incorrectly #183

Closed anarcat closed 10 months ago

anarcat commented 10 months ago

in #182, @julian-klode said:

This has all a bit too fast for me to actually give any feedback (I'm afk all week except this morning more or less), but pkgcache.bin will also get updated whenever you install or upgrade or remove a package. srcpkgcache.bin is rebuilt whenever the sources.list changes, you ran clean, or the lists actually changed.

The best approach arguably is to check /var/lib/apt/periodic/update-success-stamp to see when the last succesful update was - but it is only set by the periodic script, so that only makes sense if the option is set (querying that with apt_pkg.init_config(); apt_pkg.config["APT::Periodic::Update-Package-Lists"] is nicest if you want to use python3-apt, but could do apt-config get too).

The best proxy otherwise is just the mtime of the /var/lib/apt/lists directory as we always rename() files from the partial directory into there, so it should always be updated as far as I understand directory modification times. The modification times of the files meanwhile are the modification times on the server and hence not meaningful.

This is a common issue that other tools also have and APT itself will need to deal with, I think we're going to end up adding actual stamp files to the apt code itself so you can always tell when the last update was and whether there were errors. Maybe just dump a (machine-readable) update.log in there, once we have machine-readable error codes.

Originally posted by @julian-klode in https://github.com/prometheus-community/node-exporter-textfile-collector-scripts/issues/182#issuecomment-1765726265

So we need to tweak our cache age metric to check the mtime on /var/lib/apt/lists until APT standardizes this. I don't feel like relying on APT::Periodic stuff is sufficiently flexible to cover most use cases (few people seem aware of that feature in the first place...)

Looking at mirror files is still interesting, I think. Reporting on out-of-date mirrors is a worthwhile, but separate goal, so let's not get bogged down on that here.