dnf logging is a bit nuts

Issues related to applications and software problems and general support
Post Reply
mathog
Posts: 258
Joined: 2008/07/09 23:52:06

dnf logging is a bit nuts

Post by mathog » 2020/07/14 18:43:45

On earlier CentOS releases yum.log contained a nice succinct summary of what was installed/removed/updated and when. Conversely, pulling that information out of dnf.log is a PITA and it is so chocked full of essentially useless DEBUG and DDEBUG messages like:

Code: Select all

2020-07-14T17:31:50Z DEBUG repo: using cache for: rpmfusion-nonfree-updates
(end user, "who cares???") that they grow rapidly, logrotate has to run on it, which eventually deletes the only information in these files that I am interested in.

I eventually found that there is /var/log/dnf.rpm.log, which is very similar to the old yum.log. It is the only log file produced by dnf.log that an end user should ever look at. It contains all the useful information which is obscured in dnf.log by all the extraneous logging. (But why on earth is it

Code: Select all

2020-03-19T21:10:21Z SUBDEBUG Installed: epel-release-8-7.el8.noarch
and not

Code: Select all

2020-03-19T21:10:21Z INFO --- Installed: epel-release-8-7.el8.noarch
??? Surely install, erase, update events are informational and not debugging, let alone "SUBdebugging"!)

The strangest part is that while dnf has a "history" command it is quite tricky to get it to provide all the same information in dnf.rpm.log.

Code: Select all

grep autofs dnf.rpm.log
2020-03-25T18:59:29Z SUBDEBUG Installed: autofs-1:5.1.4-35.el8.x86_64
2020-03-25T18:59:30Z SUBDEBUG Installed: autofs-1:5.1.4-35.el8.x86_64
2020-07-14T18:18:29Z SUBDEBUG Upgrade: libsss_autofs-2.2.3-20.el8.x86_64
2020-07-14T18:18:29Z SUBDEBUG Upgrade: libsss_autofs-2.2.3-20.el8.x86_64
2020-07-14T18:26:43Z SUBDEBUG Upgrade: autofs-1:5.1.4-40.el8.x86_64
2020-07-14T18:26:44Z SUBDEBUG Upgrade: autofs-1:5.1.4-40.el8.x86_64
dnf history info autofs
Transaction ID : 33
Begin time     : Wed 25 Mar 2020 11:59:29 AM PDT
Begin rpmdb    : 873:6472340ed76d46ad80ad5bd01e0afe2bef23aded
End time       : Wed 25 Mar 2020 11:59:30 AM PDT (1 seconds)
End rpmdb      : 874:5367e5b6a9b67265092991147fb8a2f0d963f1c1
User           : root <root>
Return-Code    : Success
Releasever     : 8
Command Line   : install autofs
Packages Altered:
    Install autofs-1:5.1.4-35.el8.x86_64 @BaseOS
That is, it shows one when there are two. Also using "dnf history" cuts off some information, like here:

Code: Select all

  113 | install glusterfs gluste | 2020-03-31 14:53 | Install        |    5   
Any chance the dnf developers can be convinced to rename dnf.log to dnf.debug.log, because it is misnamed. It appears to be a typical log file for the end users but it is not, it is a tool primarily for the developers. End users need to be directed away from it because trying to use it is basically a waste of our time. Also, please eliminate both the "SUBDEBUG" and "INFO ---" strings from dnf.rpm.log, as the rest of the message holds the real information, and those tags add no value. (They can still inject DEBUG messages when debuglevel is set higher than the default in dnf.conf).

Lastly, these messages in dnf.rpm.log:

Code: Select all

2020-07-14T18:33:54Z INFO --- logging initialized ---
should go into /var/log/messages instead, as they have nothing whatsoever to do with RPM actions.

Post Reply