Question
Can DNF treat a total mirror failure as an implicit cache invalidation signal on Rocky Linux?
Mira Lane
0 reputation · 01 Apr 2020, 10:06 UTC
34.6K views1
Loading…
0 reputation · 01 Apr 2020, 10:06 UTC
Rocky Linux repositories rely on DNF's local metadata cache in /var/cache/dnf, governed by the metadata_expire interval. When every mirror in a repository's mirrorlist becomes unreachable, DNF falls back to the next mirror; if all fail, it retains the existing stale cache unless the expiration interval has already elapsed. The core uncertainty is whether a complete mirror failure should act as an implicit signal to invalidate that cache immediately, or whether the timer alone should control refresh attempts.
This behavior is not standardized uniformly across Rocky Linux releases. Rocky Linux 8 ships with DNF 4, while Rocky Linux 9 uses DNF 5, and their metadata handling plugins differ. Custom repository configurations that override metadata_expire or enable mirrorlist_expire can further change the outcome. Because the decision point between stale-cache reuse and forced refresh remains configurable but not uniformly defined, administrators need to confirm the exact behavior on their specific release and repository configuration.
Which policy governs stale-cache retention after a total mirrorlist failure in Rocky Linux 9? Does the mirrorlist_expire setting alter the decision to reuse cached metadata when no mirror is reachable? When should an operator expect DNF to serve stale data versus refusing the transaction?
35775 reputation · 01 Apr 2020, 12:31 UTC
On Rocky Linux 9, DNF does not treat a complete mirror failure as an implicit cache invalidation; it continues to serve the existing metadata cache until the metadata_expire interval expires or a successful repository access occurs.
The DNF client’s metadata handling is timer‑driven. When all URLs in the mirrorlist are unreachable, DNF simply skips network fetches and re‑uses the cached files. The metadata_expire setting (default 6 h) determines how often a fresh copy is requested, while mirrorlist_expire only refreshes the mirrorlist file itself and does not trigger a metadata refresh.
rockylinux/var/cache/dnf) after a total mirror outage; the cache is not cleared automatically.mirrorlist_expire controls how frequently the mirrorlist file is re‑downloaded; it does not affect the metadata cache.metadata_expire is set to 0 or a very low value, the cache may be refreshed far more often, but the default behavior remains timer‑based.metadata_expire value: grep ^metadata_expire /etc/dnf/dnf.conf (or any file included via dnf.conf).iptables -A OUTPUT -d -j DROP) and run a DNF command such as dnf check-update. Observe whether the transaction proceeds using cached metadata or aborts.If you can provide the exact metadata_expire value from your DNF configuration, I can confirm whether the cache would be refreshed immediately under a total mirror failure.
Use comments to ask for clarification. Post a solution as an answer.
35,775 reputation · 01 Apr 2020, 15:11 UTC
On Rocky Linux 9 with DNF 5, a total mirrorlist outage does not by itself purge /var/cache/dnf repodata. The decisive boundary is metadata_expire: if cached repodata is still within its TTL, DNF can resolve dependencies from cache while every mirror is unreachable, though package downloads will still fail. mirrorlist_expire only controls reuse of the cached mirror list; it does not force repodata invalidation. Verify the effective boundary per repository with dnf config-manager --dump, then compare dnf -v repolist inside and outside the configured metadata_expire window while mirrors are blocked.