[Rpm-maint] [rpm-software-management/rpm] Don't modify interupts if db is read only (#251)

[Jeff Johnson]

Sigh ... there are much better fixes for ^C handling than reopening an rpmdb (where ^C will *still* be disabled while installing).

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).

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
of packages that haven't been successfully upgraded and remove on exit if you want to start
towards transactional durability.

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).

The entire issue is that SOME application MUST call rpmdbClose as part of ^C handling.

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.

-- 
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/pull/251#issuecomment-315191663
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20170713/4490b2d7/attachment.html>