Description of problem:
During a Workstation install failure (due to an rpm failing to download)
I noticed that /tmp was 100% full due to /tmp/dnf.librepo.log
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Net install of RHEL 8 (Workstation)
2. Look at Diskspace in /tmp partition.
In my case having downloaded about 77% of the packages
I noticed that /tmp was 100% with dnf.librepo.log taking up 975MB!
The file has about 8 million lines with select_next_target!! ;)
/tmp not to overfill during installation.
I am not sure if this is fatal or how reproducible but I thought
I better report it anyway, since it doesn't seem good.
Okay well I just tried again and successfully netinstalled (exact same RHEL 8 WS config)
and dnf.librepo.log was only 1.6MB...
Thanks for the report. It is good to know that the log file could grow so large.
I see this as a proposal on DNF to avoid such a grow of the log.
(In reply to Jiri Konecny from comment #2)
> Thanks for the report. It is good to know that the log file could grow so
> I see this as a proposal on DNF to avoid such a grow of the log.
Definitely - seems to me like a debugging message that was left in place by mistake.
originally reported on Fedora/dnf bug 1580022
on RHEL 8 Beta I ended up with > 7 GB DEBUG level lines in dnf.librepo.log:
-rw-r--r--. 1 root root 7376408576 Mar 19 16:20 dnf.librepo.log
These turn off debug logging for librepo by default. There are other log files, the logging is fragmented and not in great shape in general. I hope we'll revisit it in the future with a more complete solution.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.