Red Hat Bugzilla – Bug 803976
rpm and updatedb cause (temporary) system lockup
Last modified: 2012-07-11 13:51:29 EDT
Description of problem:
rpm causes temporary system lockups when run. These lockups cause some X11 programs to be unresponsive (no display refresh) for time periods ~30s and then afterwards are responsive again. (Among these clients are fedora and emacs. xterm strangely enough is still responsive.) I tried to rebuild the rpm database with `rpmdb --rebuild` but it didn't help. During the rebuild rpmdb also caused these lockups. The system locks up for about 30s and is then released and this happens again after another minute or so.
In addition, even after `rpmdb --rebuild` the rpm is unbearably slow. E.g.
[root@grower dov]# time rpm -q -a > /dev/null
`top` shows that it is not a CPU issue. `lsof` doesn't reveal anything suspicious (to me). Doing strace on rpm shows that it never gets stuck on any timeout.
A related problem is that updatedb cause a similar lockup.
Version-Release number of selected component (if applicable):
# uname -a
Linux grower 184.108.40.206-3.fc15.i686 #1 SMP Mon Jan 23 15:44:18 UTC 2012 i686 i686 i386 GNU/Linux
# cat /etc/redhat-release
Fedora release 15 (Lovelock)
# rpm --version
RPM version 220.127.116.11
# updatedb --version
updatedb (mlocate) 0.24
Copyright (C) 2007 Red Hat, Inc. All rights reserved.
This software is distributed under the GPL v.2.
This program is provided with NO WARRANTY, to the extent permitted by law.
Steps to Reproduce:
1. Open firefox
2. run `rpm -q -a > /dev/null`
3. or run `updatedb`
Temporary system freeze.
Background activity without any visible impact on desktop.
System freezes on rpm, updatedb or such are kernel land, reassigning. See the timings at https://bugzilla.redhat.com/show_bug.cgi?id=752897#c28 with different kernels - the test-case timing goes from 2m 39s to 7m 53s (ie nearly triples) depending on which kernel is running. That's quite a regression, apparently related to heavy IO.
As for the rpm part, make sure you're using this update which migitates the issue somewhat: https://admin.fedoraproject.org/updates/FEDORA-2012-1510/rpm-18.104.22.168-4.fc15
I just installed that update and it made a *huge* difference in response time for rpm! :-)
Now we just need a similar fix for mlocate/updatedb.
But we can consider this bug closed or a duplicate.
The rpm update only helps to avoid triggering the worst-case scenario (whatever it is) by using a smaller cache for the rpm database.
The case is not really closed until somebody figures out what has caused the severe IO performance degration in the more recent kernels (again, see the figures in bug 752897).
Is this still happening with kernel-22.214.171.124-3.fc15 (in updates-testing)? 126.96.36.199-3.fc15 is actually quite old, several things have been fixed in that time, including several security issues.
I updated to kernel-188.8.131.52-3.fc15 and the result was as follows:
* Running `updatedb` at the default nice level still caused firefox to be inaccessible for periods of roughly 5s. This is still much better than the behaviour I experienced before.
* Running `updatedb` at nice level 19 (nicest level) causes no detectable interference in desktop use.
Since I updated rpm I can no longer test its desktop influence. Do you need me to downgrade rpm to test without the latest workaround?
Are you still seeing the updatedb issue with 2.6.43/3.3?
Fedora 15 has reached it's end of life as of June 26, 2012. As a result, we will not be fixing any remaining bugs found in Fedora 15.
In the event that you have upgraded to a newer release and the bug you reported is still present, please reopen the bug and set the version field to the newest release you have encountered the issue with. Before doing so, please ensure you are testing the latest kernel update in that release and attach any new and relevant information you may have gathered.
Thank you for taking the time to file a report. We hope newer versions of Fedora suit your needs.