This leads to a null timestamp in the metric (apt_package_cache_timestamp_seconds 0.0).
Maybe we can fallback on the other method if the file doesn't exist?
The mtime of /var/lib/apt/lists is not necessarily updated when running apt update (perhaps only if there are modifications?). This behavior differs from the previous use of /var/cache/apt/pkgcache.bin, which was consistently modified upon each update. Perhaps /var/lib/apt/lists/partial could serve as a suitable substitute in this case?
user@server:~ date
Wed Dec 13 20:35:39 UTC 2023
user@server:~ sudo apt update
user@server:~ sudo ls -la /var/lib/apt/lists | grep "Dec 13"
drwxr-xr-x 4 root root 4096 Dec 13 16:44 .
drwx------ 2 _apt root 4096 Dec 13 20:35 partial
user@servfer:~ sudo ls -la /var/cache/apt/pkgcache.bin
-rw-r--r-- 1 root root 35241413 Dec 13 20:35 /var/cache/apt/pkgcache.bin
Hi,
Since https://github.com/prometheus-community/node-exporter-textfile-collector-scripts/commit/feb943f6df8cbc536eaf7fca59a088d59bb39e82, I have encountered multiple issues with the cache timestamp:
at least on debian 12 cloud images,
APT::Periodic::Update-Package-Lists
doesn't mean that/var/lib/apt/periodic/update-success-stamp
exists:This leads to a null timestamp in the metric (
apt_package_cache_timestamp_seconds 0.0
). Maybe we can fallback on the other method if the file doesn't exist?The mtime of
/var/lib/apt/lists
is not necessarily updated when runningapt update
(perhaps only if there are modifications?). This behavior differs from the previous use of/var/cache/apt/pkgcache.bin
, which was consistently modified upon each update. Perhaps/var/lib/apt/lists/partial
could serve as a suitable substitute in this case?