Does AlmaLinux 9 dnf module system retain memory across concurrent package transactions?

Direct answer

No. DNF 5.x on AlmaLinux 9 does not retain in-memory state across separate package transactions. Each dnf invocation is its own process; when the transaction ends and the process exits, the kernel reclaims that process’s anonymous heap memory. Concurrent module activations do not create a shared memory pool that survives after the last dnf process terminates.

Confirmed behavior vs likely explanation

Confirmed: DNF 5.x loads repository metadata and solves dependencies in memory for the duration of a single run. High-volume module streams enlarge that in-memory metadata cache, which can raise RSS while the process is alive. After exit, that allocation disappears from the process view.

Likely explanation, not a confirmed leak: what appears as sustained retention is typically the Linux kernel page cache holding recently read repository and RPM data. Page cache is reported in the buff/cache column, not as a leak in a specific dnf PID, and it is released under system-wide memory pressure rather than immediately after a transaction completes.

Cgroup throttling and concurrent activation

If multiple dnf transactions run under a cgroup with MemoryLimit=, the kernel can reclaim page cache and, under sustained pressure, swap anonymous memory. This can suppress RSS growth but does not change the per-process lifecycle: each dnf process still owns its own heap. Heavy concurrency may prolong occupancy indirectly through RPM database lock contention, keeping a dnf process alive longer and therefore keeping its memory resident longer.

Verification steps for this case

1. Confirm no dnf processes remain after the transaction: ps -o pid,rss,cmd -C dnf
2. Compare process memory with system cache: free -m before and after, watching buff/cache versus used.
3. Isolate a single PID’s heap from shared mappings while a transaction runs: grep -E '^(Rss|Pss|Private_Dirty):' /proc/$PID/smaps
4. Test cgroup pressure safely: systemd-run --scope -p MemoryLimit=512M dnf module list and observe whether the command completes or is killed.

Assumptions and uncertainty

This answer assumes the default AlmaLinux 9 DNF 5.x stack. DNF 4 behavior on AlmaLinux 8 is not a reliable proxy for AlmaLinux 9. No specific package set is known to maximize persistent retention by design; DNF has no cross-transaction memory retention setting. Large module metadata sets increase per-run footprint only.

Missing diagnostic detail

Are you measuring RSS while dnf processes are still running, or after every dnf process has exited? That distinction determines whether the observation is process heap retention or page-cache behavior, and it changes the next step.