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:	dnf	Assignee:	Lukáš Hrázký <lhrazky>
Status:	CLOSED ERRATA	QA Contact:	Jan Blazek <jblazek>
Severity:	unspecified	Docs Contact:
Priority:	medium
Version:	8.0	CC:	apevec, dmach, james.antill, jkonecny, lhrazky, mblaha, mihai, mkolman
Target Milestone:	rc	Keywords:	Triaged
Target Release:	8.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
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):
anaconda-29.19.0.34-1.el8

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:
https://github.com/rpm-software-management/libdnf/pull/707
https://github.com/rpm-software-management/dnf/pull/1363

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.

https://access.redhat.com/errata/RHSA-2019:3583