Stale DNF metadata cache in Rocky Linux: diagnosing repodata freshness and expiry defaults

DNF4 Metadata Expiry and Diagnostics

In Rocky Linux 8 and 9, DNF4 typically defaults to a metadata_expire value of 48 hours when not explicitly defined in the repository configuration. This means DNF will not attempt to refresh the repomd.xml from the mirror unless the local cache is older than this threshold.

Confirming Defaults on a Live System

Because the default is often compiled into the DNF binary rather than written in the .repo files, you can confirm the current status and expiration of your active repositories using the following command:

dnf repolist -v

Look for the Expiry field in the output for each repository. This indicates when DNF next considers the local metadata stale. Additionally, you can verify the physical age of the cached metadata by checking the timestamps in the DNF cache directory:

ls -l /var/cache/dnf/

Pinning metadata_expire: Best Practices

Whether to pin metadata_expire in /etc/yum.repos.d/ depends on your environment's stability requirements:

• Leave as Default: Recommended for general-purpose workstations or servers where a 48-hour lag in package availability is acceptable. This minimizes unnecessary load on community mirrors.
• Pin to Lower Value: Recommended for CI/CD pipelines or production environments that require immediate access to point-release updates or security patches. Adding metadata_expire=3600 (1 hour) ensures freshness but increases mirror traffic.

Distinguishing Stale Cache from Mirror Lag

Intermittent 404 errors during package downloads are often confused with stale metadata. You can distinguish between a local cache issue and a remote mirror synchronization lag using this logic:

1. Force a metadata refresh: Run dnf clean expire-cache. This removes only the metadata that has expired, forcing DNF to fetch the latest repomd.xml.
2. Test the download: Attempt the package installation again.
3. Analyze the result:
   • If the 404 persists immediately after a fresh metadata download, the issue is Mirror Sync Lag. The mirror's metadata is updated, but the actual package RPM has not yet been synced to that specific mirror's filesystem.
   • If the 404 disappears, the issue was a Stale Local Cache referencing a package version that the mirror had already pruned.

Diagnostic Note: To provide a more specific recommendation, please clarify if you are using a local mirror/satellite server or connecting directly to the public Rocky Linux mirror list.