Bug 1598554 - dnf appears to hang because of lack of user feedback
Summary: dnf appears to hang because of lack of user feedback
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: dnf
Version: 28
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: rpm-software-management
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1599102 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-07-05 19:21 UTC by Federic
Modified: 2018-11-23 07:43 UTC (History)
8 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2018-09-27 13:13:11 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
Snippet of my /var/log/dnf.log (18.08 KB, text/plain)
2018-11-23 06:00 UTC, Scott Cohen
no flags Details
Command output that goes with previously posted snippet. (18.49 KB, text/plain)
2018-11-23 06:04 UTC, Scott Cohen
no flags Details

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.


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