So corruption in this case means that any rpm operation that reads or writes to
BDB will fail, because the db fails to open. In our case, all rpm operations
are done as root. As you can see, this is reproducible as root:
```
[root@redacted ~]# for i in {1..30}; do /bin/rpm -qa &>/dev/null & done
[1] 84680
[2] 84681
[3] 84682
...
[30] 84710
[root@redacted ~]# rpm -qa
error: db4 error(-30974) from dbenv->open: DB_RUNRECOVERY: Fatal error, run
database recovery
error: cannot open Packages index using db4 - (-30974)
error: cannot open Packages database in /opt/yum/var/lib/rpm
error: db4 error(-30974) from dbenv->open: DB_RUNRECOVERY: Fatal error, run
database recovery
error: cannot open Packages index using db4 - (-30974)
error: cannot open Packages database in /opt/yum/var/lib/rpm
```
Also, please note that during sandboxing I did not disallow writes to the rpm
directory, just to the disk-backed mmapped regions
(`/opt/yum/var/lib/rpm.__db.*`). The .dbenv file locks are still written (not
sure if these are the shared locks you are talking about). It sounds like the
fsync stub may be responsible for what we are seeing here.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/232#issuecomment-307660544
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
