Bug 1599102 - DNF, at certain times, takes a couple minutes to start up
Summary: DNF, at certain times, takes a couple minutes to start up
Keywords:
Status: CLOSED DUPLICATE of bug 1598554
Alias: None
Product: Fedora
Classification: Fedora
Component: dnf
Version: 28
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Marek Blaha
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-07-08 22:40 UTC by Scott Cohen
Modified: 2018-07-16 11:17 UTC (History)
6 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2018-07-16 11:17:01 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
This is the output of dnf doing an update with the -yv switches and timed. (4.26 KB, text/plain)
2018-07-08 22:40 UTC, Scott Cohen
no flags Details
My /etc/dnf/dnf.conf (101 bytes, text/plain)
2018-07-08 23:28 UTC, Scott Cohen
no flags Details
The dnf.librepo.log from July 8th. (14.69 MB, text/plain)
2018-07-09 18:30 UTC, Scott Cohen
no flags Details

Description Scott Cohen 2018-07-08 22:40:50 UTC
Created attachment 1457324 [details]
This is the output of dnf doing an update with the -yv switches and timed.

Description of problem:
Either right after Fedora boots (not verified for shutdown but is for reboot)) or after a long period of inactive use of the DNF command, the command takes a couple minutes to start and then go onto its routines. The part where DNF takes the longest is after it outputs the plugins it loaded. The following is a snippet from the output which exemplifies this erroneous behavior (I forgot if the text: cachedir: /var/cache/dnf showed up during the following snippet or after):
Loaded plugins: builddep, config-manager, copr, debug, debuginfo-install, download, generate_completion_cache, needs-restarting, playground, repoclosure, repograph, repomanage, reposync, system-upgrade
DNF version: 2.7.5 

Version-Release number of selected component (if applicable):
dnf-2.7.5-12.fc28

How reproducible:
Almost after every boot and/or inactive use of the command.

Steps to Reproduce:
1. Reboot machine or don't use the dnf command for several hours (in my experience 10 is a magic number)
2. Execute the dnf command once either of the conditions in 1 have been met.

Actual results:
It takes several minutes to start up dnf after execution of command.

Expected results:
Only a couple of seconds or less is to be experienced before the cache is read.

Additional info:
This occurs no matter what command is ran with dnf once the conditions, explained above, are met.

Comment 1 Scott Cohen 2018-07-08 23:28:21 UTC
Created attachment 1457325 [details]
My /etc/dnf/dnf.conf

Comment 2 Marek Blaha 2018-07-09 11:50:44 UTC
Please, can you provide us with /var/log/dnf.librepo.log?

Comment 3 Scott Cohen 2018-07-09 18:30:42 UTC
Created attachment 1457561 [details]
The dnf.librepo.log from July 8th.

(In reply to Marek Blaha from comment #2)
> Please, can you provide us with /var/log/dnf.librepo.log?

This is the the librepo log from July 8th.

Comment 4 Daniel Mach 2018-07-16 11:17:01 UTC

*** This bug has been marked as a duplicate of bug 1598554 ***


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