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.
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.
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?
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.
Yes, I would move this problem to selinux, permissive mode should not affect executable behavior afaik.
*** This bug has been marked as a duplicate of 245389 ***