<p>Sigh ... there are much better fixes for ^C handling than reopening an rpmdb (where ^C will <em>still</em> be disabled while installing).</p>
<p>For starters, the signal handling in RPM was designed to be polled at code points where the rpmdb is known to be consistent (for a graceful exit with an rpmdbClose when that makes sense).</p>
<p>Adding the poll in 10-15 places in rpm code SHOULD lead to reasonable ^C handling (i.e. responsiveness in seconds, not minutes) as well as no rpmdb stateful problems. Run a list<br>
of packages that haven't been successfully upgraded and remove on exit if you want to start<br>
towards transactional durability.</p>
<p>There is also an approach using atexit(2), as well as an approach with chained signal handlers (but that will likely need collusion with depsolvers that use rpmlib).</p>
<p>The entire issue is that SOME application MUST call rpmdbClose as part of ^C handling.</p>
<p>Pretending that O_RDONLY doesn't write locks in the dbenv (including the transaction lock) when run as root is an act of ignorant denial.</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/pull/251#issuecomment-315191663">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/ANb809BqfqjjSqZht3c6zXGtqWHLQpQtks5sNnzjgaJpZM4OVV72">mute the thread</a>.<img alt="" height="1" src="https://github.com/notifications/beacon/ANb805UvlcGFgl7ZnmcU_nOUf_FyK1N8ks5sNnzjgaJpZM4OVV72.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/pull/251#issuecomment-315191663"></link>
  <meta itemprop="name" content="View Pull Request"></meta>
</div>
<meta itemprop="description" content="View this Pull Request 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":"@n3npq in #251: Sigh ... there are much better fixes for ^C handling than reopening an rpmdb (where ^C will *still* be disabled while installing).\r\n\r\nFor starters, the signal handling in RPM was designed to be polled at code points where the rpmdb is known to be consistent (for a graceful exit with an rpmdbClose when that makes sense).\r\n\r\nAdding the poll in 10-15 places in rpm code SHOULD lead to reasonable ^C handling (i.e. responsiveness in seconds, not minutes) as well as no rpmdb stateful problems. Run a list\r\nof packages that haven't been successfully upgraded and remove on exit if you want to start\r\ntowards transactional durability.\r\n\r\nThere is also an approach using atexit(2), as well as an approach with chained signal handlers (but that will likely need collusion with depsolvers that use rpmlib).\r\n\r\nThe entire issue is that SOME application MUST call rpmdbClose as part of ^C handling.\r\n\r\nPretending that O_RDONLY doesn't write locks in the dbenv (including the transaction lock) when run as root is an act of ignorant denial."}],"action":{"name":"View Pull Request","url":"https://github.com/rpm-software-management/rpm/pull/251#issuecomment-315191663"}}}</script>