-
Notifications
You must be signed in to change notification settings - Fork 194
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
report the apt cache timestamp #182
report the apt cache timestamp #182
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor naming nit, otherwise, LGTM.
We use the `pkgcache.bin` modification time as a heuristic, but there might be a better way to do this. We also silently ignore errors when pulling that file to avoid broken systems from breaking the other metrics. I believe this will lead to a null metric which is probably what we want anyway. A possible improvement to this would be to individually inspect the `InRelease` files and report the mirror's timestamps as well, but that's more involved. It's also not a priority compared to this fix, because we want the update timestamp if we remove the `apt update` run (in prometheus-community#181). Closes: prometheus-community#180 Signed-off-by: Antoine Beaupré <[email protected]> Co-authored-by: Ben Kochie <[email protected]>
2ba296a
to
dc6568e
Compare
merged your suggestion in the commit, along with a credit in commitlog, should be ready to merge now. |
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. The best approach arguably is to check The best proxy otherwise is just the mtime of the 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. |
great feedback @julian-klode - i've opened #183 to tweak this properly. |
As reported in prometheus-community#182, `pkgcache.bin` gets updated on more than just `apt update`. In particular, it gets modified when a package is installed, upgraded or removed. So let's fallback on a better heuristic, which is the `lists` directory, which gets updated when new mirror lists gets moved into place. This does run the risk of staying silently unchanged if there's no change on mirrors but (a) that's rather infrequent and (b) we might actually want to warn on that anyway.
As reported in prometheus-community#182, `pkgcache.bin` gets updated on more than just `apt update`. In particular, it gets modified when a package is installed, upgraded or removed. So let's fallback on a better heuristic, which is the `APT::Periodic` timestamp. This should give us a much more precise and deliberate status. We also fallback to the `lists` directory, which gets updated when new mirror lists gets moved into place. This does run the risk of staying silently unchanged if there's no change on mirrors but (a) that's rather infrequent and (b) we might actually want to warn on that anyway. Signed-off-by: Antoine Beaupré <[email protected]>
As reported in prometheus-community#182, `pkgcache.bin` gets updated on more than just `apt update`. In particular, it gets modified when a package is installed, upgraded or removed. So let's fallback on a better heuristic, which is the `APT::Periodic` timestamp. This should give us a much more precise and deliberate status. We also fallback to the `lists` directory, which gets updated when new mirror lists gets moved into place. This does run the risk of staying silently unchanged if there's no change on mirrors but (a) that's rather infrequent and (b) we might actually want to warn on that anyway. Signed-off-by: Antoine Beaupré <[email protected]> Closes: prometheus-community#183
As reported in prometheus-community#182, `pkgcache.bin` gets updated on more than just `apt update`. In particular, it gets modified when a package is installed, upgraded or removed. So let's fallback on a better heuristic, which is the `APT::Periodic` timestamp. This should give us a much more precise and deliberate status. We also fallback to the `lists` directory, which gets updated when new mirror lists gets moved into place. This does run the risk of staying silently unchanged if there's no change on mirrors but (a) that's rather infrequent and (b) we might actually want to warn on that anyway. Signed-off-by: Antoine Beaupré <[email protected]> Closes: prometheus-community#183
As reported in prometheus-community#182, `pkgcache.bin` gets updated on more than just `apt update`. In particular, it gets modified when a package is installed, upgraded or removed. So let's fallback on a better heuristic, which is the `APT::Periodic` timestamp. This should give us a much more precise and deliberate status. We also fallback to the `lists` directory, which gets updated when new mirror lists gets moved into place. This does run the risk of staying silently unchanged if there's no change on mirrors but (a) that's rather infrequent and (b) we might actually want to warn on that anyway. Signed-off-by: Antoine Beaupré <[email protected]> Closes: prometheus-community#183
We use the
pkgcache.bin
modification time as a heuristic, but there might be a better way to do this.We also silently ignore errors when pulling that file to avoid broken systems from breaking the other metrics. I believe this will lead to a null metric which is probably what we want anyway.
A possible improvement to this would be to individually inspect the
InRelease
files and report the mirror's timestamps as well, but that's more involved. It's also not a priority compared to this fix, because we want the update timestamp if we remove theapt update
run (in #181).Closes: #180