Bug 1136212

Summary: yum check execution takes extremely long time
Product: Red Hat Enterprise Linux 6 Reporter: Frantisek Reznicek <freznice>
Component: yumAssignee: Valentina Mukhamedzhanova <vmukhame>
Status: CLOSED ERRATA QA Contact: Karel Srot <ksrot>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 6.5CC: esammons, freznice, james.antill, pmatilai, vmukhame
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: yum-3.2.29-63.el6 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-07-22 07:21:24 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
packed /var/lib/rpm rpm databases (from RHEL 6.5 i686)
none
backported patch none

Description Frantisek Reznicek 2014-09-02 07:51:09 UTC 
Description of problem:

yum check hangs.

When I tried multiple times on multiple machines RHEL 6.5 / 6.6 Server i686 / x86_64 (some KVM, some bare metal) I realized yum check is not moving forward and taking much more time than I expected for all of them (5 machines). There was no other yum running, machines were not subscribed to RHN, there was no network problem as installation was working as expected.

Average yum check execution was over 10 minutes (5 machines).

Users are not going to be happy with this behavior as there is no information about progress atm.

If yum check is going to take more time (as there are new operations added) then users need to be aware yum check is doing the work not just hanging.


Version-Release number of selected component (if applicable):
yum-3.2.29-43.el6_5.noarch
yum-3.2.29-60.el6.noarch

How reproducible:
100%

Steps to Reproduce:
1. yum check


Actual results:
yum check operation takes extremely long time.

Expected results:
yum check operation takes less time or yum check provides user a operation status info.

Additional info:

# yum check
Loaded plugins: auto-update-debuginfo, product-id, security, subscription-manager
This system is not registered to Red Hat Subscription Management. You can use subscription-manager to register.
<hang for >8 minutes>
check all
#
Comment 2 Frantisek Reznicek 2014-09-02 08:41:59 UTC 
Please note -d 9 or --verbose swithes do not bring more light into what yum is actually doing.
Comment 5 Frantisek Reznicek 2014-09-02 10:38:45 UTC 
Created attachment 933689 [details]
packed /var/lib/rpm rpm databases (from RHEL 6.5 i686)
Comment 7 Frantisek Reznicek 2014-09-02 11:05:31 UTC 
Same behavior seen on older yum& rpm as well (RHEL 6.4)

# rpm -q yum rpm
yum-3.2.29-40.el6.noarch
rpm-4.8.0-37.el6.x86_64
Comment 8 Frantisek Reznicek 2014-09-02 11:39:42 UTC 
My initial thought was that something changed recently which is not correct as same behavior is reproducible on RHEL 6.1 x86_64:

# rpm -q yum rpm
yum-3.2.29-17.el6.noarch
rpm-4.8.0-16.el6_1.1.x86_64

# time yum check
check all

real    9m31.613s
user    8m39.071s
sys     0m51.106s
Comment 9 James Antill 2014-09-04 13:27:06 UTC 
 Is it "check provides" that's the problem? Do you have a lot of kernel-debug packages installed or something? Basically what does:

 rpm -qa --provides | wc -l

...say? We had an upstream "fix" for this a bit ago, we could backport that fairly easily.

commit 406fbca7d1020fcf6c9d3d98c02bf8198ea90d57
Author: James Antill <james>
Date:   Mon Jun 2 13:04:03 2014 -0400

    Have check provides check directly against the rpm index, and then quit.
Comment 10 James Antill 2014-09-04 13:28:16 UTC 
Probably the easiest way to see if that's the problem is to git clone the upstream code, and run: ./yummain.py check
Comment 16 Valentina Mukhamedzhanova 2014-12-11 12:44:07 UTC 
Created attachment 967216 [details]
backported patch
Comment 21 errata-xmlrpc 2015-07-22 07:21:24 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://rhn.redhat.com/errata/RHBA-2015-1384.html