<p>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:</p>
<pre><code>[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
</code></pre>
<p>Also, please note that during sandboxing I did not disallow writes to the rpm directory, just to the disk-backed mmapped regions (<code>/opt/yum/var/lib/rpm.__db.*</code>). 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.</p>

<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br />You are receiving this because you are subscribed to this thread.<br />Reply to this email directly, <a href="https://github.com/rpm-software-management/rpm/issues/232#issuecomment-307660544">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/ANb800pT1UqMGViS92xAKj_xs6vEdws3ks5sDGcAgaJpZM4NzFoB">mute the thread</a>.<img alt="" height="1" src="https://github.com/notifications/beacon/ANb80151z5z8ol7hh6DUdbsK5v41Y84Uks5sDGcAgaJpZM4NzFoB.gif" width="1" /></p>
<div itemscope itemtype="http://schema.org/EmailMessage">
<div itemprop="action" itemscope itemtype="http://schema.org/ViewAction">
  <link itemprop="url" href="https://github.com/rpm-software-management/rpm/issues/232#issuecomment-307660544"></link>
  <meta itemprop="name" content="View Issue"></meta>
</div>
<meta itemprop="description" content="View this Issue on GitHub"></meta>
</div>

<script type="application/json" data-scope="inboxmarkup">{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/rpm-software-management/rpm","title":"rpm-software-management/rpm","subtitle":"GitHub repository","main_image_url":"https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open in GitHub","url":"https://github.com/rpm-software-management/rpm"}},"updates":{"snippets":[{"icon":"PERSON","message":"@smorad in #232: 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:\r\n```\r\n[root@redacted ~]# for i in {1..30}; do /bin/rpm -qa \u0026\u003e/dev/null \u0026 done\r\n[1] 84680\r\n[2] 84681\r\n[3] 84682\r\n...\r\n[30] 84710\r\n[root@redacted ~]# rpm -qa\r\nerror: db4 error(-30974) from dbenv-\u003eopen: DB_RUNRECOVERY: Fatal error, run database recovery\r\nerror: cannot open Packages index using db4 -  (-30974)\r\nerror: cannot open Packages database in /opt/yum/var/lib/rpm\r\nerror: db4 error(-30974) from dbenv-\u003eopen: DB_RUNRECOVERY: Fatal error, run database recovery\r\nerror: cannot open Packages index using db4 -  (-30974)\r\nerror: cannot open Packages database in /opt/yum/var/lib/rpm\r\n```\r\n\r\nAlso, 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."}],"action":{"name":"View Issue","url":"https://github.com/rpm-software-management/rpm/issues/232#issuecomment-307660544"}}}</script>