Bug 587651
| Summary: | Too much time for nothing | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Yanko Kaneti <yaneti> | ||||
| Component: | yum | Assignee: | Seth Vidal <skvidal> | ||||
| Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | low | ||||||
| Version: | rawhide | CC: | ffesti, james.antill, maxamillion, pmatilai, tim.lauridsen | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2010-04-30 13:39:38 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
It's doing "yum check dependencies duplicates", because the assumption is that the remote repos. aren't going to knowingly be broken. So when it hits a problem yum makes sure that there isn't a local problem. However what does "time sudo yum check duplicates dependencies" say? Does it take that long for multiple runs? Here it's like 3 seconds. Yanko, Has this system been upgraded a lot from release to release? Just for fun run: time rpm -Va --nofiles --nodigest then rpm --rebuilddb then time rpm -Va --nofiles --nodigest and post the results. thanks yum check duplicates dependencies takes ~6 seconds, and nothing other than Loaded plugins: changelog, refresh-packagekit check duplicates yum update , with everything cached an no network access takes 1m14.103s with 98% of it between the last two lines. Your NOTABUG resolution seems premature. Seth: It has been a rawhide from around f10 or so... before rebuilddb: # time rpm -Va --nofiles --nodigest real 0m45.016s user 0m40.081s sys 0m4.565s after: # time rpm -Va --nofiles --nodigest real 0m44.525s user 0m39.670s sys 0m4.617s Perhaps it gets overwhelmed by both 13, main, updates and testing and rawhide repos being enabled at the same time. Its a fairly legitimate config at this point of development. Yanko, just to be sure - as root cd /var/lib/rpm rm __db* rpm --rebuilddb and run rpm -Va --nofiles --nodigest again 45s is long unless this system is particularly slow, has very low mem or has LOTS of pkgs installed. rpm -qa | wc -l would also be useful thx Seth, Its still roughly 45s. 2GHz Phenom. There is plenty of memory. # rpm -qa | wc -l 3286 Yanko can you run time yum check w/o any additional arguments? thanks Eek, had to run this twice to double check. # time yum check Loaded plugins: changelog, refresh-packagekit check all real 19m19.813s user 19m15.490s sys 0m2.078s # time yum check Loaded plugins: changelog, refresh-packagekit check all real 19m13.960s user 19m10.771s sys 0m1.746s > yum check duplicates dependencies
> takes ~6 seconds, and nothing other than
Ahh, sorry, I thought I'd changed that. The command only takes one arg. at a time although the API doesn't. So you'd have to test:
yum check duplicates
yum check dependencies
...and "check dependencies" does take about 2x "check duplicates" here. So that'd be about 18 seconds (in total) for you I guess?
Saying that you do have a _lot_ of packages installed, and 19 minutes for a full "yum check" is ... err. impressive. Can you run:
for i in dependencies duplicates obsoleted provides; do
echo $i
time sudo yum check
done
...my guess is that it's the "provides" check, which we could take out of the default if so.
okay - 19m is completely bonkers. something is SERIOUSLY wrong there - if you can - compress and attach your rpmdb. also run: yum repolist please check duplicates 0m5.360s check dependencies 1m7.827s check obsoleted 0m18.460s check provides 19m12.700s # yum repolist Loaded plugins: changelog, refresh-packagekit repo id repo name status chromium Chromium Test Packages 14 fedora Fedora 13 - x86_64 20,800 google Google - i386 4 livna-development Livna for Fedora Core 13 - x86_64 - Development 3 rawhide Fedora - Rawhide - Developmental packages for t 20,926 rpmfusion-free-rawhide RPM Fusion for Fedora 13 - Free - Rawhide 489 rpmfusion-nonfree-rawhide RPM Fusion for Fedora 13 - Non-Free - Rawhide 168 testgnomeshell Testgnomeshell 93 testkoji Testkoji 3,040 updates Fedora 13 - x86_64 - Updates 0 updates-testing Fedora 13 - x86_64 - Test Updates 1,707 repolist: 47,244 As I said in comment 4, both 13 and rawhide enabled on purpose. Also I have a custom distroverpkg which is at 13 The rpm db is ~50MB compressed which might be a problem for bugzilla. You can get it from here http://declera.com/~yaneti/rpmdb.tar.xz check dependencies 1m7.827s check provides 19m12.700s These are almost certainly due to: % rpm --dbpath /tmp -qa erlang\* | wc -l 59 % rpm --dbpath /tmp -q erlang-snmp --requires | wc -l 943 % rpm --dbpath /tmp -q erlang-snmp --provides | wc -l 1538 ...which should be fixed "soon". Indeed. Its much better now. # time yum check dependencies Loaded plugins: auto-update-debuginfo, changelog, refresh-packagekit check dependencies real 0m10.907s user 0m7.546s sys 0m0.415s # time yum check provides Loaded plugins: auto-update-debuginfo, changelog, refresh-packagekit check provides real 0m23.019s user 0m22.315s sys 0m0.547s |
Created attachment 410430 [details] yum -d 9 update log Description of problem: Here is an excerpt of the end of a unsuccessful yum update (do to broken deps, to be expected) . ........ Error: Package: fontmatrix-0.6.99-5.r1073.fc14.x86_64 (@rawhide) Requires: libpodofo.so.0.6.99()(64bit) Removing: podofo-libs-0.7.0-4.fc13.x86_64 (@rawhide) libpodofo.so.0.6.99()(64bit) Updated By: podofo-libs-0.8.0-1.fc14.x86_64 (rawhide) Not found You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest The problem is that there is almost a minute of waiting and yum eating 99% (of 1 core) cpu between "You could try using --skip-broken to work around the problem" and the last line. Whatever yum is doing after the depsolving phase, I can't see the point of it given it has already bailed on the transaction as a whole. yum-3.2.27-9.fc14.noarch