Bug 1678598 - Net install caused /tmp to run out of space due to flood in dnf.librepo.log
Summary: Net install caused /tmp to run out of space due to flood in dnf.librepo.log
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: dnf
Version: 8.0
Hardware: Unspecified
OS: Unspecified
medium
unspecified
Target Milestone: rc
: 8.0
Assignee: Lukáš Hrázký
QA Contact: Jan Blazek
URL:
Whiteboard:
Depends On: 1681084
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-02-19 07:41 UTC by Jens Petersen
Modified: 2020-11-14 10:40 UTC (History)
8 users (show)

Fixed In Version: dnf-4.2.6-1.el8
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-11-05 22:21:13 UTC
Type: Bug
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2019:3583 0 None None None 2019-11-05 22:21:30 UTC

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


Note You need to log in before you can comment on or make changes to this bug.