Bug 244738 - rpm db lockup with selinux == permissive
Summary: rpm db lockup with selinux == permissive
Keywords:
Status: CLOSED DUPLICATE of bug 245389
Alias: None
Product: Fedora
Classification: Fedora
Component: rpm
Version: 7
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Paul Nasrat
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-06-18 20:39 UTC by Wolfgang Rupprecht
Modified: 2007-11-30 22:12 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-07-17 14:27:26 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Wolfgang Rupprecht 2007-06-18 20:39:26 UTC
Description of problem:

There is an eventual rpm-db lock problem when selinux is active.   After about
6 hours on my machine programs that use the rpm-db will fail with a lock error.
This occurs when selinux is "permissive".   (I haven't run with "enforcing" so 
I have no idea if it happens then too.) When selinux is set to "disable" 
the problem goes away.  Maybe this should be filed against selinux?

This example is via system-config-users. Under the hood it is checking the
rpm database. (I don't have access to a failing system 
right now and the only saved failure was this one.)  The same thing happened 
when I ran 'yum update', but unfortunately I didn't save the output. 

A reboot clears this up for a short amount of time.

[root@arbol ~]# system-config-users 
rpmdb: Lock table is out of available locker entries
rpmdb: Unknown locker ID: 7db
error: db4 error(22) from db->close: Invalid argument
error: cannot open Packages index using db3 - Cannot allocate memory (12)
error: cannot open Packages database in /var/lib/rpm
Traceback (most recent call last):
  File "/usr/share/system-config-users/system-config-users.py", line 46, in <module>
    mainWindow.mainWindow()
  File "/usr/share/system-config-users/mainWindow.py", line 236, in __init__
    selinuxEnabled = self.isSELinuxEnabled()
  File "/usr/share/system-config-users/mainWindow.py", line 869, in isSELinuxEnabled
    if self.isSELinuxInstalled():
  File "/usr/share/system-config-users/mainWindow.py", line 863, in
isSELinuxInstalled
    mi = ts.dbMatch('name', 'policy-sources')
TypeError: rpmdb open failed
[root@arbol ~]# 

Version-Release number of selected component (if applicable):
rpm-4.4.2-46.fc7

How reproducible:
Fully reproducable with a time delay of 6-12hrs here.

Steps to Reproduce:
1. set selinux to premissive
2. reboot
3. wait 6-12 hrs
4. yum update -y
5. observe yum fail early on when it tries to read the rpm db.
  
Actual results:

Yum fails with an error indicating it couldn't get a lock for the rpm db.

Expected results:

Yum should do its work without bailing out.

Additional info:

My gut suspicion is that this is a lock leakage problem induced by selinux that
has nothing to do with rpm.  Something is consuming a critical lock resource 
when selinux is set to permissive.

Comment 1 Jeff Johnson 2007-06-19 19:06:56 UTC
The core issue of running out of lock entry slots is in a Berkeley DB environment used by rpm,
not anywhere else.

Permissive selinux should not have changed any behavior.

I run (and develop) rpm-4.4.9+ on f7 with selinux disabled and have never seen the reported issue.

Comment 2 Wolfgang Rupprecht 2007-06-19 19:20:51 UTC
If you run with selinux *disabled* you will not see the problem.  You need to run
with it enabled in *permissive* mode.

Are the db locks done with purely user-level code or is there a kernel resource
involved too?  Is there a global resource limit that some other berkeley db can
be using up?


Comment 3 Jeff Johnson 2007-06-20 02:34:31 UTC
Again, selinux permissive mode should change no executable behavior, but
should leave an audit trail. Do you see audit entries?

Posix shared mutexes through NPTL using kernel futexes is used for locking.

The error msg
    rpmdb: Lock table is out of available locker entries
    rpmdb: Unknown locker ID: 7db
is a user land msg.

Comment 4 Jeff Johnson 2007-06-20 02:35:40 UTC
Yes, I would move this problem to selinux, permissive mode should not affect executable behavior
afaik.

Comment 5 Panu Matilainen 2007-07-17 14:27:26 UTC

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


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