Bug 485780

Summary: rpm futex hang over __db files
Product: [Fedora] Fedora Reporter: Wendell Baker <bakers2832>
Component: rpmAssignee: Panu Matilainen <pmatilai>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: 9CC: ffesti, jnovy, pmatilai
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 112811 Environment:
Last Closed: 2009-03-18 13:47:49 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 Wendell Baker 2009-02-16 19:14:01 UTC
Description of problem:

rpm hangs in futex

$ strace rpm -i something.rpm
...snip...
open("/var/lib/rpm/__db.002", O_RDWR|O_LARGEFILE) = 4
fcntl64(4, F_SETFD, FD_CLOEXEC)         = 0
mmap2(NULL, 1318912, PROT_READ|PROT_WRITE, MAP_SHARED, 4, 0) = 0xb7b91000
close(4)                                = 0
stat64("/var/lib/rpm/__db.003", {st_mode=S_IFREG|0644, st_size=450560, ...}) = 0
open("/var/lib/rpm/__db.003", O_RDWR|O_LARGEFILE) = 4
fcntl64(4, F_SETFD, FD_CLOEXEC)         = 0
mmap2(NULL, 450560, PROT_READ|PROT_WRITE, MAP_SHARED, 4, 0) = 0xb7b23000
close(4)                                = 0
stat64("/var/lib/rpm/Packages", {st_mode=S_IFREG|0644, st_size=54423552, ...}) = 0
open("/var/lib/rpm/Packages", O_RDONLY|O_LARGEFILE) = 4
fcntl64(4, F_SETFD, FD_CLOEXEC)         = 0
read(4, "\0\0\0\0\1\0\0\0\0\0\0\0a\25\6\0\10\0\0\0\0\20\0\0\0\10\0\0b&\0\0"..., 512) = 512
close(4)                                = 0
open("/var/lib/rpm/Packages", O_RDONLY|O_LARGEFILE) = 4
fcntl64(4, F_SETFD, FD_CLOEXEC)         = 0
fstat64(4, {st_mode=S_IFREG|0644, st_size=54423552, ...}) = 0
futex(0xb7b6e70c, FUTEX_WAIT, 1, NULL <unfinished ...>
<hung>


Version-Release number of selected component (if applicable):
$ rpm -q -a | egrep -E -e '(kernel|glibc|rpm)'
glibc-common-2.8-8.i386
rpm-devel-4.4.2.3-2.fc9.i386
kernel-devel-2.6.27.5-41.fc9.i686
kernel-headers-2.6.27.7-53.fc9.i386
rpm-libs-4.4.2.3-2.fc9.i386
rpm-4.4.2.3-2.fc9.i386
kernel-2.6.26.6-79.fc9.i686
kernel-firmware-2.6.27.7-53.fc9.noarch
glibc-headers-2.8-8.i386
kernel-2.6.27.5-41.fc9.i686
kernel-devel-2.6.26.6-79.fc9.i686
kernel-2.6.27.7-53.fc9.i686
rpm-build-4.4.2.3-2.fc9.i386
redhat-rpm-config-9.0.2-1.fc9.noarch
kerneloops-0.12-1.fc9.i386
rpm-python-4.4.2.3-2.fc9.i386
kernel-devel-2.6.27.7-53.fc9.i686
glibc-2.8-8.i686
glibc-devel-2.8-8.i386

$ cat /etc/fedora-release 
Fedora release 9 (Sulphur)



How reproducible:
It's unclear how to reproduce this behavior; it is clear how to remediate.  It hasn't begun to occur interactively in my sight.  I have only remediated  The system has been doing automatic updates off of PackageKit for many months now.  Today I returned to this machine after a month or so and found multiple weeks worth of rpmq weekly cron jobs piled up.  Thus the symptom clearly started spontaneously many weeks ago (which isn't helpful for us here).  The computer is a Fujitsu tablet operated by a 10-year old who runs Firefox, gimp and gnucash (very gently); and doesn't run yum or rpm.

Remediation:
$ su
# cd /var/lib/rpm
# ls
Basenames     __db.000  __db.002  Dirnames  Group       Name      Providename     Pubkeys      Requireversion  Sigmd5
Conflictname  __db.001  __db.003  Filemd5s  Installtid  Packages  Provideversion  Requirename  Sha1header      Triggername
# rm -f __db.???
# ps -ef | grep rpm
root      8906  8750  0 10:28 pts/2    00:00:00 strace rpm -i something.noarch.rpm
root      8907  8706  0 10:28 pts/2    00:00:00 rpm -i something.noarch.rpm
# kill -9 8907
# exit
$ rpm -i some-package.noarch.rpm
<success!>

Additional info:
Bugzilla 112811 was closed 2007-11 for inattention.  This seems to be exactly that same problem but now occurring on Fedora 9.

Comment 1 Panu Matilainen 2009-03-18 13:47:49 UTC
All it takes is a single rpm (or rpm-using, such as yum / PackageKit) process to crash or get forcefully terminated for this to happen.

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