Some notes on what Fedora's DNF logs and where

September 12, 2020

In comments on my entry on why Fedora release upgrades are complicated and painful for me, Ben Cotton wound up asking me to describe my desired experience for DNF's output during a release upgrade. This caused me to go out and look at what DNF actually logs today (as opposed to its console output), so here are some notes. The disclaimers are that this is on my Fedora systems, which I think are reasonably stock but may not be, and that this isn't documented that I could find in a quick skim of DNF manpages, so I'm probably wrong about parts.

DNF logs to /var/log in three separate files, dnf.log, dnf.rpm.log, and dnf.librepo.log. Of these, dnf.librepo.log appears to be the least interesting, as all my version has is information about what metadata and packages have been downloaded and some debugging information if checksums don't match.

The dnf.log file contains copies of the same information about what package updates will be done and were done as dnf itself prints interactively. It also contains a bunch of debug information about DNF's cache manipulation, usage of deltarpm, the dates of repository metadata, and other things of less interest (at least to me). It looks like it's possible to reconstruct most or all of your DNF command lines from the information here, which could be useful under some circumstances.

Finally, dnf.rpm.log has the really interesting stuff. This seems to be a verbose log of the RPM level activity that DNF does (or did during a upgrade or package install). This includes the actual packages upgraded and removed, verbose information about .rpmnew and .rpmsave files being created and manipulated (which is normally printed by RPM itself), and what seems to be a copy of most output from RPM package scripts, including output that doesn't seem to normally get printed to the terminal by DNF. This is a gold mine if you want to go back through an upgrade to look for RPM package messages that you didn't spot at the time, although you'll have to pick through a lot of debugging output.

(I initially thought that dnf.rpm.log contained all output, but at lease during Fedora release upgrades it appears to miss some things that are printed to the terminal based on my notes and script captures.)

When DNF (or perhaps RPM via DNF) reports upgrades interactively, these go in two stages; the new version of the package is upgraded (ie installed), which will run its postinstall script, and then later there is a cleanup of the old version of the package, which will run its postrm script (if any). dnf.rpm.log doesn't appear to use the same terminology when it logs the second phase. The upgrade phase appears as 'SUBDEBUG Upgrade: ...', but the cleanup phase seems to be reported as 'SUBDEBUG Upgraded: ...'. If you remove something, for example because an old kernel is being removed when you install a new one, it's reported as 'SUBDEBUG Erase:'. When a new package is installed (including a new kernel), it is reported as 'SUBDEBUG Installed:', instead of the 'Install:' that you might expect for symmetry with upgrades.

(I don't know how downgrades or obsoletes are reported; I haven't dug through my DNF logs that much.)

Unlike interactive DNF, dnf.rpm.log doesn't record the mere fact that scriptlets have been run. If they're run and don't produce any output that the log captures, they're invisible. This is probably not a problem for logging purposes; interactively, it's mostly useful as a hint to why DNF seems to be sitting around not doing anything.

None of these logs are a complete replacement for capturing a DNF session with script, as far as I can tell (although some of my information here is effectively from the Fedora 30 version of DNF, not the Fedora 31 or 32 ones). However they're at least a useful supplement, and skimming them is faster than using 'less -r ...' on a script capture of a DNF session.

Written on 12 September 2020.
« My take on permanent versus temporary HTTP redirects in general
Rolling distribution releases versus periodic releases are a tradeoff »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sat Sep 12 00:15:33 2020
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.