Bug 1220776

Summary: yumex-dnf hangs on launch
Product: [Fedora] Fedora Reporter: Mike Simms <micsim2007>
Component: yumex-dnfAssignee: Tim Lauridsen <tim.lauridsen>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 22CC: tim.lauridsen
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-05-14 14:17:04 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
terminal output while running yumex-dnf
none
yumex-dnf -d output as requested
none
sudo LIBREPO_DEBUG=1 /usr/share/dnfdaemon/dnfdaemon-system -d -v --notimeout
none
yumex-dnf -d output as requested - 18:00 GMT none

Description Mike Simms 2015-05-12 12:14:27 UTC
Created attachment 1024556 [details]
terminal output while running yumex-dnf

Description of problem:yumex-dnf is locking up when run from MATE Control Center. It gets stuck while refreshing package metadata. The subject line may not be the issue but that is the point it is freezing at as you will see from the attached terminal output

Version-Release number of selected component (if applicable):yumex-dnf-4.1.2-1.fc22


How reproducible:Consistently


Steps to Reproduce:
1. Start MATE
2. Open Control Center
3. Run yumex-dnf

Actual results: Process freezes shortly after rendering GUI


Expected results: Refresh package metadata from servers and load a list of updates if any available


Additional info:Nothing is showing in the dnf.log when yumex-dnf is executed. I have tried adding ip_resolve=4 to the dnf.conf file in case it was a DNS issue. It made no difference. traditional yumex is responding as normal and working fine on the same system and there are no issues in the browser either with DNS or server pings.

Comment 1 Tim Lauridsen 2015-05-13 05:10:56 UTC
Could you try running yumex-dnf -d and attach the output

Comment 2 Tim Lauridsen 2015-05-13 09:16:49 UTC
This message is not a issue, I comes when Gtk is importing the UI from a builder xml file. 

Gtk-CRITICAL **: gtk_window_add_accel_group: assertion 'GTK_IS_WINDOW (window)' failed

Comment 3 Mike Simms 2015-05-13 09:45:08 UTC
Created attachment 1024979 [details]
yumex-dnf -d output as requested

Hi Tim, as requested please find the attached. I've just let the program run this morning while I've got on with other stuff. As you will see the program did not freeze as I thought it had. It is just taking an exceedingly long time to process the repo and meta data.

Either way, to the average user it appears to be frozen due to the apparent lack of activity.

Thanks for the information about the GTK+ error.

Comment 4 Tim Lauridsen 2015-05-13 11:48:33 UTC
Looks very strange

07:30:56: Lock the DNF root daemon
07:30:56: Refresh system cache
08:01:23: on_RepoMetaDataProgress (root): ('Fedora 22 - x86_64 - Test Updates', 0.0)
08:31:35: on_RepoMetaDataProgress (root): ('Fedora 22 - x86_64 - Test Updates', 0.011401439288502666)

30 min for requesting refresh of dnf cache to repo meta data starts downloading
30 min from metadata download starts til the first data starts to download.


There must be something wrong with the networks connection, normally it only takes a coulple seconds to repo metadata download starts and the user see the
progress in the dialog.

Comment 5 Tim Lauridsen 2015-05-13 11:52:59 UTC
On my system (F21), with a no cache (dnf clean all, before running yumex-dnf)

13:49:00: Lock the DNF root daemon
13:49:02: on_RepoMetaDataProgress (root): ('RPM Fusion for Fedora 21 - Free', 0.0)
13:49:03: on_RepoMetaDataProgress (root): ('RPM Fusion for Fedora 21 - Free', 0.01950218500863144)

Comment 6 Mike Simms 2015-05-13 12:59:50 UTC
As much as I could I already checked the network configuration to try and rule that out before opening this ticket. I really wish it was that simple.

The old non-dnf yumex in F22 MATE on the same system responds and performs normally. there are no 30 minute delays.

do you want me to run a verbose output on yumex for comparison?

I've tried yumex-dnf with IPv6 enabled and disabled in dnf.conf and Network Manager.

Also DNS server settings (google - 8.8.8.8 and OpenDNS 208.67.222.222) are checking out okay. There are no delays or issues looking up sites or downloading data in Firefox. even wget from the command line can access the fedora, updates and updates-testing servers okay if I try downloading an rpm just to test the connection to servers.

I will do dnf clean all and run it again this evening but I would expect the same results.

Comment 7 Tim Lauridsen 2015-05-13 13:59:08 UTC
try to run 

dnf clean all
dnf makecache

to see if also takes very long time to complete

Comment 8 Tim Lauridsen 2015-05-13 15:13:22 UTC
If you can reproduce the issue, then try to run

sudo LIBREPO_DEBUG=1 /usr/share/dnfdaemon/dnfdaemon-system -d -v --notimeout

in one terminal window and run

yumex-dnf -d

in another windows and attach the output from both.

this can be related to bug 1219283

Comment 9 Mike Simms 2015-05-13 17:19:56 UTC
Created attachment 1025126 [details]
sudo LIBREPO_DEBUG=1 /usr/share/dnfdaemon/dnfdaemon-system -d -v --notimeout

Okay, so dnf clean all followed by dnf makecache caused the same behaviour.

I've run the commands you posted in your last post and the process seems to have completed as it should this time.

yumex-dnf -d output to follow

Comment 10 Mike Simms 2015-05-13 17:22:59 UTC
Created attachment 1025127 [details]
yumex-dnf -d output as requested - 18:00 GMT

To go with https://bugzilla.redhat.com/attachment.cgi?id=1025126

Comment 11 Mike Simms 2015-05-14 14:17:04 UTC

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