Bug 1678598

Summary: Net install caused /tmp to run out of space due to flood in dnf.librepo.log
Product: Red Hat Enterprise Linux 8 Reporter: Jens Petersen <petersen>
Component: dnfAssignee: Lukáš Hrázký <lhrazky>
Status: CLOSED ERRATA QA Contact: Jan Blazek <jblazek>
Severity: unspecified Docs Contact:
Priority: medium    
Version: 8.0CC: apevec, dmach, james.antill, jkonecny, lhrazky, mblaha, mihai, mkolman
Target Milestone: rcKeywords: Triaged
Target Release: 8.0   
Hardware: Unspecified   
OS: Unspecified   
Fixed In Version: dnf-4.2.6-1.el8 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-11-05 22:21:13 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On: 1681084    
Bug Blocks:    

Description Jens Petersen 2019-02-19 07:41:28 UTC
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
being 975MB!

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.

Actual results:
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!! ;)

Expected results:
/tmp not to overfill during installation.

Additional info:
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.

Comment 1 Jens Petersen 2019-02-19 08:35:03 UTC
Okay well I just tried again and successfully netinstalled (exact same RHEL 8 WS config)
and dnf.librepo.log was only 1.6MB...

Comment 2 Jiri Konecny 2019-02-19 09:37:01 UTC
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.

Comment 3 Martin Kolman 2019-02-19 12:12:56 UTC
(In reply to Jiri Konecny from comment #2)
> 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.

Definitely - seems to me like a debugging message that was left in place by mistake.

Comment 6 Alan Pevec 2019-03-19 20:53:25 UTC
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

Comment 7 Lukáš Hrázký 2019-03-27 19:06:58 UTC
Pull requests:

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.

Comment 13 errata-xmlrpc 2019-11-05 22:21:13 UTC
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.