Bug 803976

Summary:	rpm and updatedb cause (temporary) system lockup
Product:	[Fedora] Fedora	Reporter:	Dov Grobgeld <dov.grobgeld>
Component:	kernel	Assignee:	Kernel Maintainer List <kernel-maint>
Status:	CLOSED WONTFIX	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	15	CC:	ffesti, gansalmon, itamar, jforbes, jnovy, jonathan, kernel-maint, madhu.chinakonda, pmatilai
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-07-11 17:51:29 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:

Description Dov Grobgeld 2012-03-16 07:58:19 UTC

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

real 1m13.801s
user 0m7.181s
sys 0m0.239s

`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 2.6.41.10-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 4.9.1.2
# 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.

How reproducible:

Every time.

Steps to Reproduce:
1. Open firefox
2. run `rpm -q -a > /dev/null`
3. or run `updatedb`

Actual results:

Temporary system freeze.

Expected results:

Background activity without any visible impact on desktop.

Additional info:

Comment 1 Panu Matilainen 2012-03-16 08:19:43 UTC

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-4.9.1.2-4.fc15

Comment 2 Dov Grobgeld 2012-03-16 08:57:11 UTC

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.

Comment 3 Panu Matilainen 2012-03-16 09:13:29 UTC

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).

Comment 4 Justin M. Forbes 2012-03-16 18:51:07 UTC

Is this still happening with kernel-2.6.42.10-3.fc15 (in updates-testing)? 2.6.41.10-3.fc15 is actually quite old, several things have been fixed in that time, including several security issues.

Comment 5 Dov Grobgeld 2012-03-17 21:50:01 UTC

I updated to kernel-2.6.42.10-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?

Comment 6 Josh Boyer 2012-06-07 17:57:54 UTC

Are you still seeing the updatedb issue with 2.6.43/3.3?

Comment 7 Josh Boyer 2012-07-11 17:51:29 UTC

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.