Fedora Disk Cleanup: What DNF Already Does Before You Add a Cron Job

The cron job that duplicates DNF's own defaults

A Fedora workstation starts reporting a nearly full root filesystem, and the reflex is to add a weekly dnf clean all job to cron. On most systems that mostly repeats work DNF already performs, and it throws away repository metadata you will immediately re-download.

The useful engineering decision is not "should I clean the cache" but "which of DNF's three separate cleanup mechanisms am I trying to influence." Cached package files, repository metadata, and orphaned dependencies are governed by different settings, and only one of them is really about disk space.

Three different things called cleanup

Cached package files

The keepcache option in /etc/dnf/dnf.conf controls whether downloaded RPMs survive a successful transaction. When it is false, DNF deletes them after installation; when true, they stay in the cache directory.

Repository metadata

metadata_expire is a duration, not a background timer. After that window passes, the next dnf command considers cached repodata stale and refetches it. So "automatic refresh" happens when you run a command, not on a schedule.

Orphaned dependencies

clean_requirements_on_remove controls whether erasing a package also erases dependencies that nothing else needs. dnf autoremove applies the same logic to packages that are already orphaned.

One caution: some summaries describe a setting named clean_requirements_on_disk. I could not confirm that name against DNF's documented options, and the option that governs dependency cleanup on erase is clean_requirements_on_remove. Treat any *_on_disk spelling as unverified and check your own configuration dump.

Worked example: auditing a Fedora workstation

Start read-only, as your normal user. Use sudo only where noted.

# 1. What is explicitly set in the config file?
grep -E '^(keepcache|metadata_expire|clean_requirements_on_remove)' /etc/dnf/dnf.conf

# 2. What is actually in force? (DNF4-based releases)
dnf config-manager --dump | grep -E 'keepcache|metadata_expire|clean_requirements_on_remove'

# 3. How much is the cache holding?
du -sh /var/cache/dnf 2>/dev/null; du -sh /var/cache/libdnf5 2>/dev/null

Step 1 frequently prints nothing, because defaults are compiled in rather than written to the file; an empty result does not mean "unset." Step 2 is the one that matters. On DNF5-based Fedora, config-manager may not accept --dump, so check dnf config-manager --help for the equivalent or read the values from the config files alongside man 5 dnf.conf. Step 3 checks two locations because DNF5 moved its cache out of /var/cache/dnf.

Next, list orphan candidates without changing anything:

# Shows the transaction and asks for confirmation; answer "no".
dnf autoremove

# Or decline automatically:
dnf autoremove --assumeno

Read the list before accepting it. Expected check: neither of these commands should remove anything, and your installed package count should be unchanged. If the list contains a tool you invoke directly, stop there.

If the list is genuinely stale, apply it with sudo dnf autoremove. This changes system state, so record the transaction ID from dnf history; sudo dnf history undo <ID> reverses it. Compare dnf list --installed | wc -l before and after as a sanity check.

The trade-off: autoremove trusts a bookkeeping list

DNF decides what is an orphan from its record of which packages you installed explicitly. That record can be incomplete for software installed outside DNF, such as via rpm -i or a vendor installer, and for a dependency you later began using as a command-line tool. Those can appear unneeded. Separately, keepcache=true is a deliberate trade: keeping RPMs helps machines that reinstall often or share a cache, but costs disk space.

What to actually do

• Leave keepcache at its default unless you have a concrete reason to retain RPMs.
• Do not schedule dnf clean all; it discards metadata as well as packages. If you want space back, dnf clean packages is narrower.
• Run dnf autoremove interactively a few times a year rather than from cron, so you actually read the list.
• Verify metadata behavior by running dnf makecache and observing whether it downloads or reports the cache as fresh; the timestamps under the repodata directory show when it last changed.

Version assumption: Fedora 41 and later ship DNF5 by default, while Fedora 39 and 40 use DNF4. The option names above are DNF4 spellings, so confirm them against man 5 dnf.conf on your release. Because this area is flagged as needing current verification, treat specific default values as something to check locally rather than assume.