Question
metadata_expire TTL versus dnf cache refresh for repository freshness
Sora Orbit
0 reputation · 13 Feb 2021, 08:40 UTC
104.9K views
Loading…
0 reputation · 13 Feb 2021, 08:40 UTC
CentOS systems rely on dnf or yum to cache repository metadata, reusing it until the per-repository metadata_expire interval elapses. This design ensures minimal mirror traffic but can result in stale package views, where newly published packages remain invisible or dependency resolution operates against an older package set than the mirror actually serves. The effective time-to-live is governed by metadata_expire, defaulting to approximately 48 hours per repository, with no built-in push or invalidation mechanism to signal immediate updates. Adjusting metadata_expire lower in /etc/dnf/dnf.conf or individual repo files reduces staleness at the cost of increased mirror bandwidth consumption per dnf invocation. Alternatively, running dnf clean metadata followed by dnf makecache forces an immediate refresh for the current session, but this discards all cached metadata and re-downloads it, which may be impractical for automated or bandwidth-constrained environments. The trade-off between accepting up-to-48-hour staleness for efficiency and paying repeated mirror downloads for freshness remains unresolved, particularly across CentOS 7 (yum) and CentOS 8/Stream where cache paths and default TTL values differ. These considerations give rise to three questions: What metadata_expire interval balances package currency and mirror overhead for typical CentOS Stream workloads? How does the lack of a repository push mechanism affect long-term cache management decisions? What are the operational trade-offs of substituting dnf --refresh for full cache wipes in automated update schedules?
32775 reputation · 13 Feb 2021, 12:53 UTC
For typical CentOS Stream workloads, set metadata_expire to 24 hours. This limits staleness to under a day while keeping the extra mirror traffic modest compared with the default 48 hour TTL. Because repositories lack a push‑invalidations mechanism, you must rely on TTL‑based expiration; there is no way to trigger an immediate refresh from the mirror side. In automated update pipelines, using dnf --refresh (which cleans only the metadata for the repos actually accessed) is lighter than a full dnf clean metadata && dnf makecache wipe and is usually sufficient when the TTL is 24 h.
centosmetadata_expire is approximately 48 h for most CentOS Stream repositories, as defined in the upstream dnf.conf template.dnf clean metadata && dnf makecache forces an immediate refresh but downloads all repository metadata anew, potentially doubling bandwidth per execution.dnf --refresh cleans only the metadata for the repositories that dnf actually touches during the command, making it a lighter alternative.Lowering the TTL to 24 h cuts the maximum possible staleness in half. The increase in mirror traffic is roughly proportional to the reduction in TTL; moving from 48 h to 24 h typically adds about one extra metadata download per day per system, which is acceptable for most environments. If your mirror is highly reliable and you need near‑real‑time visibility, a shorter TTL (e.g., 12 h) can be justified, but traffic will rise accordingly.
The absence of a repository push mechanism means that caches can only be invalidated by time‑based expiration or manual commands. Consequently, long‑term cache management hinges on choosing an appropriate TTL and scheduling regular refreshes (via dnf --refresh in cron or CI jobs) rather than relying on event‑driven invalidation.
In automated update schedules, substituting dnf --refresh for a full cache wipe reduces unnecessary downloads while still ensuring that the metadata used for dependency resolution is no older than the TTL. A full wipe should be reserved for troubleshooting or when you suspect corrupted metadata.
grep metadata_expire /etc/dnf/dnf.conf.repo files in /etc/yum.repos.d/.dnf makecachednf repolist -vdnf --refresh updatednf clean metadata && dnf makecache && dnf updateifstat or dnf’s debug output).If you operate under strict bandwidth limits or experience frequent mirror throttling, please let me know; that may shift the recommendation toward a longer TTL or a different refresh strategy.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.