Bug 1598554

Summary: dnf appears to hang because of lack of user feedback
Product: [Fedora] Fedora Reporter: Federic <feddy>
Component: dnfAssignee: rpm-software-management
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 28CC: dmach, jmracek, mblaha, mhatina, packaging-team-maint, rpm-software-management, vmukhame, yetoohappy
Target Milestone: ---Keywords: Triaged
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-09-27 13:13:11 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:
Embargoed:
Attachments:
Description Flags
Snippet of my /var/log/dnf.log
none
Command output that goes with previously posted snippet. none

Description Federic 2018-07-05 19:21:08 UTC 
Description of problem:
dnf update does nothing for a couple of minutes with no output. gives the impression it has hung.

Version-Release number of selected component (if applicable):


How reproducible:
always

Steps to Reproduce:
1.having not used dnf for several days ( exceeded cache refresh time ? )
2.dnf update
3.

Actual results:
having hit return, cursor moves to a new line with no output ( no prompt, nothing ). It takes a couple of minutes before the first output whereby it reports last sync time was .. a few minutes ago.

Expected results:
an instant confirmation that it is doing something useful and is not crashed. It seems to be doing an online check of some sort: this is evidently quite long and  a confirmation of what is happening and a warming that it may take a while would reassure the user. 

Additional info:
Comment 1 Marek Blaha 2018-07-09 11:32:36 UTC 
Can you try to run dnf in verbose mode and provide us with dnf.log?
$ dnf -v update
Comment 2 Marek Blaha 2018-07-09 12:05:15 UTC 
And please, what version of dnf are you using? (rpm -q dnf)
Comment 3 Federic 2018-07-09 17:21:18 UTC 
DNF version: 2.7.5
Comment 4 Daniel Mach 2018-07-16 11:16:18 UTC 
We believe this is fixed in DNF 3.x.
Keeping open to verify.
Comment 5 Daniel Mach 2018-07-16 11:17:01 UTC 
*** Bug 1599102 has been marked as a duplicate of this bug. ***
Comment 6 Jaroslav Mracek 2018-09-27 13:13:11 UTC 
We enhanced repo download process when we report something already before server reply. The problem is solved in dnf-3.5.1
Comment 7 Scott Cohen 2018-09-27 15:50:57 UTC 
Is there any chance this fix will be backported to the DNF 2.x series for Fedora 28? This is a serious usability issue out of box.
Comment 8 Jaroslav Mracek 2018-09-27 15:53:51 UTC 
Unfortunately no, but the latest dnf can de downloaded from our repository even for f28 (dnf copr enable rpmsoftwaremanagement/dnf-nightly)
Comment 9 Scott Cohen 2018-11-22 18:52:48 UTC 
This is still occurring with dnf-4.0.4-2.fc29.noarch. I will attempt to get logs with more testing.
Comment 10 Scott Cohen 2018-11-23 06:00:27 UTC 
Created attachment 1508211 [details]
Snippet of my /var/log/dnf.log

This is the log illustrating the issue I got with dnf-4.0.4-2.fc29.rpm.
Comment 11 Scott Cohen 2018-11-23 06:04:41 UTC 
Created attachment 1508212 [details]
Command output that goes with previously posted snippet.

I believe the hang either started at "enabling rpmfusion-nonfree-source repository", "DNF version: 4.0.4", or "cachedir: /var/cache/dnf". Unfortunately I forget which, but hopefully I will keep track in subsequent testing.
Comment 12 Federic 2018-11-23 07:43:46 UTC 
here is a snip from my log. The delay occurred after "Unknown configuration option" line appeared. The delay was a lot shorter than it used to be, maybe 20s. 


2018-11-23T08:32:22Z DEBUG DNF version: 2.7.5
2018-11-23T08:32:22Z DDEBUG Command: dnf update
2018-11-23T08:32:22Z DDEBUG Installroot: /
2018-11-23T08:32:22Z DDEBUG Releasever: 28
2018-11-23T08:32:22Z DEBUG cachedir: /var/cache/dnf
2018-11-23T08:32:22Z DDEBUG Base command: update
2018-11-23T08:32:22Z DDEBUG Extra commands: ['update']
2018-11-23T08:32:22Z DEBUG Unknown configuration option: enable = 1 in /etc/yum.repos.d/playonlinux.repo
2018-11-23T08:32:46Z DEBUG reviving: failed for 'updates', mismatched sha256 sum.
2018-11-23T08:32:46Z DDEBUG repo: downloading from remote: updates, _Handle: metalnk: https://mirrors.fedoraprojec$


I've removed the faulty repo now, since I do not use it.