Question
Rocky Linux retry safety limits: atomic DNF payloads versus repeated RPM scriptlet writes
Sora Indigo
0 reputation · 08 Jan 2025, 15:02 UTC
93.2K views1
Loading…
0 reputation · 08 Jan 2025, 15:02 UTC
Rocky Linux uses DNF to manage packages, and its download layer retries transient network failures according to configured retry, timeout, and minrate values. Completed payloads are written to temporary files and renamed into place, which prevents duplicated or truncated package files on a re-attempted download. The unresolved boundary sits at the RPM transaction layer: %pre and %post scriptlet side effects—such as creating users, appending configuration lines, or seeding caches—are not automatically idempotent and are not rolled back if a transaction is interrupted and then re-run. Although dnf history rollback can revert package payloads and rpmdb changes, it does not undo external scriptlet writes, so duplicated side effects can persist. Because default retry settings and the DNF generation differ across Rocky minor releases, the exact behavior must be verified against the installed version.
Which retry and timeout defaults apply to the installed Rocky minor release, and do they vary by DNF generation? Is there a documented packaging requirement or DNF/RPM mechanism that guarantees %post scriptlet writes are safe to repeat after an interrupted transaction? Does dnf history rollback on Rocky Linux ever include external side effects from scriptlets, or are those always outside its scope?
32775 reputation · 08 Jan 2025, 20:10 UTC
In Rocky Linux, network retry behavior is controlled by the retries and timeout settings in /etc/dnf/dnf.conf. Across Rocky Linux minor releases, the default values are:
These defaults apply to the download layer. DNF downloads payloads to a temporary location before passing them to RPM. If a download fails, DNF retries the fetch without re-executing any scriptlets, since scriptlets run only during the RPM transaction phase.
RPM does not provide native idempotency or rollback for scriptlet side effects. The %pre and %post scripts are executed as shell scripts. If an interruption occurs after a scriptlet creates a user, modifies a config file, or writes to an external location, but before the RPM database records the installation, a retry will re-run those scripts. Package maintainers must implement idempotency manually using conditional checks (e.g., checking if a user exists before creating it).
The dnf history rollback command is limited to the package manager's state. It can:
It cannot undo external side effects from scriptlets. Changes to system configuration files, created users, or directories outside the package's file list remain after a rollback.
To verify your system's configuration:
rockylinuxgrep -E "^(retries|timeout)" /etc/dnf/dnf.confTo inspect a package's scriptlets for idempotency:
rpm -qp --scripts <package>.rpmTo check the DNF version:
dnf --versionUse comments to ask for clarification. Post a solution as an answer.
No question comments on this page.