Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 225376 - weird RPM database locking problem with yum
Summary: weird RPM database locking problem with yum
Status: CLOSED DUPLICATE of bug 213963
Alias: None
Product: Fedora
Classification: Fedora
Component: yum
Version: 6
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Jeremy Katz
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2007-01-30 08:15 UTC by Jon Masters
Modified: 2014-01-21 22:57 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2007-01-30 13:54:53 UTC

Attachments (Terms of Use)

Description Jon Masters 2007-01-30 08:15:23 UTC
Description of problem:

So I did the standard install song and dance on a desktop recently. Fresh FC6
install, removed yum-updatesd (and that pup applet too), symlinked the binary
location so neither will ever run again, made sure nothing was using rpm exact
explicit invocations of yum...

[jcm@perihelion ~]$ sudo yum install dia
Loading "installonlyn" plugin
Setting up Install Process
Setting up repositories
Reading repository metadata in from local files
Parsing package install arguments

What's it really doing?

6084  open("/var/lib/rpm/Packages", O_RDONLY|O_LARGEFILE) = 9
6084  fcntl64(9, F_SETFD, FD_CLOEXEC)   = 0
6084  fstat64(9, {st_dev=makedev(253, 0), st_ino=1343499, st_mode=S_IFREG|0644,
st_nlink=1, st_uid=37, st_gid=37, st_blksize=4096, st_blocks=63352,
st_size=32399360, st_atime=2007/01/30-02:47:45, st_mtime=2007/01/21-12:40:38,
st_ctime=2007/01/21-12:40:38}) = 0
6084  rt_sigprocmask(SIG_BLOCK, ~[RTMIN RT_1], [], 8) = 0
6084  rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
6084  futex(0xb7bed7c0, FUTEX_WAIT, 2, NULL) = -1 EINTR (Interrupted system call)

Ok, let's run python under gdb and see what it wants to do:

0x005c3402 in __kernel_vsyscall ()
(gdb) bt
#0  0x005c3402 in __kernel_vsyscall ()
#1  0x00d0d98e in __lll_mutex_lock_wait () from /lib/
#2  0x00d097fc in _L_mutex_lock_85 () from /lib/
#3  0x00d0933d in pthread_mutex_lock () from /lib/
#4  0x009ee28f in __db_pthread_mutex_lock_rpmdb ()
   from /usr/lib/
#5  0x00a8f9e0 in __memp_fget_rpmdb () from /usr/lib/
#6  0x00a60510 in __db_goff_rpmdb () from /usr/lib/

Some kind of locking semantics in librpmdb - I don't know that library. But I've
seen this before (yum trying to FUTEX_WAIT seemingly without any reason) and the
only "solution" seems to be rebooting the machine. lsof confirms nothing else
has that library mapped, nothing with "rpm" in the name is open, no processes
and no files. I haven't yet installed debug versions of these packages to persue
this any further - is this a standard issue I'm hitting again and again?


Comment 1 Jon Masters 2007-01-30 08:29:49 UTC
A quick reboot and the machine is ok again. Next time, I'll capture a list of
processes and then init down to single user just to be certain nothing else is
in the way before I reboot...


Comment 2 Jeremy Katz 2007-01-30 13:54:53 UTC

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

Note You need to log in before you can comment on or make changes to this bug.