Stale DNF metadata after system clock rollback

Question

Stale DNF metadata after system clock rollback
The goal is to understand how DNF decides whether its cached repository metadata remains valid when the system clock is set backward, potentially bypassing the metadata_expire timer.
Constraints include differences in cache layout and expiration logic between DNF releases prior to version 4.0 and later versions, the absence of an automatic mechanism to detect clock adjustments, and the possibility that simultaneous metadata refreshes from multiple processes could produce partial or corrupted cache files.

Does DNF treat metadata as stale immediately after a backward clock change, or does it rely solely on the metadata_expire timer?
How does DNF coordinate concurrent metadata refreshes to avoid creating incomplete or corrupted cache files?
Are there any version‑specific safeguards that mitigate the risk of using stale metadata under these conditions?

Tasadduq Burney · Answer

Answer
DNF does not automatically mark repository metadata as stale when the system clock is moved backward. It continues to consider the metadata valid until the metadata_expire interval (based on the file’s modification time) elapses relative to the current system time.
Likely explanation
When the clock rolls back, the modification timestamp of existing metadata files may appear newer than the current time. DNF’s freshness test (mtime + metadata_expire > now) therefore still evaluates to true, so the cache is deemed fresh until the timer expires.
Confirmed facts

DNF determines freshness by comparing mtime + metadata_expire to the current system time; there is no automatic clock‑rollback detector.
Concurrent metadata updates are protected by a lock file (/var/cache/dnf/metadata_lock) and an atomic rename of a temporary file to the final location, preventing partial or corrupted cache files.
Starting with DNF 4.0 (Fedora 28) the lock implementation was strengthened and a SHA256 checksum of the downloaded repomd.xml is verified, reducing corruption risk, but the version still relies on metadata_expire for staleness.

Steps needed for this case

Check the installed DNF version: dnf --version.
Verify the metadata_expire setting in /etc/dnf/dnf.conf or repo files (look for metadata_expire=).
If you need to force a refresh after a clock rollback, run dnf clean metadata followed by dnf makecache (or simply invoke any DNF command, which will trigger a refresh once the timer expires).
Optionally, monitor the lock file during a refresh to confirm coordination: ls -l /var/cache/dnf/metadata_lock while a command is running.

Missing diagnostic detail
If your metadata_expire is set to 0 or a very low value, the metadata will be considered stale almost immediately regardless of clock changes; confirming this setting would change the recommendation from “wait for timer” to “metadata is already stale”. Please provide the current metadata_expire value if you need a more precise answer.

Stale DNF metadata after system clock rollback

Stale DNF metadata after system clock rollback

1 answer

Answer

Likely explanation

Confirmed facts

Steps needed for this case

Missing diagnostic detail

Your perspective belongs here.

0 question comments