Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 225376 - weird RPM database locking problem with yum
weird RPM database locking problem with yum
Status: CLOSED DUPLICATE of bug 213963
Product: Fedora
Classification: Fedora
Component: yum (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jeremy Katz
Depends On:
  Show dependency treegraph
Reported: 2007-01-30 03:15 EST by Jon Masters
Modified: 2014-01-21 17:57 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-01-30 08:54:53 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Jon Masters 2007-01-30 03:15:23 EST
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/libpthread.so.0
#2  0x00d097fc in _L_mutex_lock_85 () from /lib/libpthread.so.0
#3  0x00d0933d in pthread_mutex_lock () from /lib/libpthread.so.0
#4  0x009ee28f in __db_pthread_mutex_lock_rpmdb ()
   from /usr/lib/librpmdb-4.4.so
#5  0x00a8f9e0 in __memp_fget_rpmdb () from /usr/lib/librpmdb-4.4.so
#6  0x00a60510 in __db_goff_rpmdb () from /usr/lib/librpmdb-4.4.so

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 03:29:49 EST
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 08:54:53 EST

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