[Rpm-maint] [rpm-software-management/rpm] Rpm query causes corruption in the file-backed mmaped bdb regions (#232)

Panu Matilainen notifications at github.com
Mon Jun 12 10:40:47 UTC 2017

There's an endless row of  bugs where BDB environment getting corrupted, some of which have been BDB bugs (several found just in the last couple of years) that have been patched in Fedora/RHEL libdb but upstream BDB 5.x does not have, dunno about 6.x but there you run into the licensing side. So if you're running upstream BDB 5.x on Mac, you'll want to a check those Fedora/RHEL patches to libdb. Some of the more exotic bugs have been kernel VM, virtualization and whatnot.
Fsync is only disabled on the first open of a newly created database (ie during fresh install), (iirc) never on existing database unless forced via configuration.

After adding the .dbenv.lock to serialize rpmdb open and close a few years ago (to work around what seems like a BDB bug), I haven't been able to reproduce environment corruption from parallel access in my setup but doesn't mean it doesn't happen in some other setup, version mix and whoknowswhat.

One possible workaround is to force use of private environment. That also means practically no locking, but at least it means queries will not corrupt anything (however queries themselves could return garbage if run in middle of write-operation). That's what happens if you run queries as non-privileged user, but since you can control permissions with sandboxing you can achieve the same by disallowing open of /var/lib/rpm/.dbenv.lock, which causes rpm to fall back to a private environment  - meaning it wont open, much less write to those __db.* files.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20170612/47357e8b/attachment-0001.html>

More information about the Rpm-maint mailing list