Re: [Rpm-maint] [rpm-software-management/rpm] Don't modify interupts if db is read only (#251)
Curiosity aside, as generally noted this is not right from upstream perspective. NAK. -- 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-339948556___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Don't modify interupts if db is read only (#251)
Closed #251. -- 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#event-1313760753___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Don't modify interupts if db is read only (#251)
I'm actually curious as to what the use-case for this patch is, because at least with the cli tools of rpm itself, queries and the like have "always" stopped fast enough with the existing polling mechanism. Now that transactions run with signals blocked, we could move the signal polls into the various iter-next functions if that helps, but that wouldn't help anything if it's some other software (depsolvers etc) that's not polling for interrupts in their own busy-loops. -- 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-339296375___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Don't modify interupts if db is read only (#251)
I'm happy it works fine for SuSE: I'm sure you have tested. Meanwhile ^C exiting and calling rpmdbClose is a problem that needs to be solved without convoluted BDB configuration changes. Its tiresome to continuously revisit this issue, in patches and bug reports. -- 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-315361310___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Don't modify interupts if db is read only (#251)
Trust me, the patch works fine for the setup used at SUSE. But I agree that it makes no sense to merge it. -- 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-315360381___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Don't modify interupts if db is read only (#251)
@mischroe: DB_PRIVATE has its own associated durability/signal problems, including that ^C is masked while installing, and with the transaction lock being for exclusive writers, not readers. Truly ^C handling needs to be solved intelligently, not with convoluted contortions to BDB configuration. Been there, done that, hacks to BDB configuration and verification ever worked well enough. Adding ~10-15 checks on signal receipt and calling rpmdbClose exits within seconds. The entire issue is that rpmdbClose needs to be called before exit, particularly with ^C. And most of the complaints about "corruption" (for the entirely different case of "kill -9") disappear if 10 lines of code are added to automate DB_RUNRECOVERY. -- 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-315358868___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Don't modify interupts if db is read only (#251)
Just a note to remember that for generating new roots (i.e. not inplace upgrades), we can just let SIGINT kill us. For rpm-ostree, every operation is a new root, so we [turn off rpm's SIGINT completely](https://github.com/projectatomic/rpm-ostree/commit/ddf2227ae9a7d91b8e7e580dbe8c5d21120d24d6). -- 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-315350162___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Don't modify interupts if db is read only (#251)
I guess thats something else we should upstream or standardize with upstream on. -- 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-315323245___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Don't modify interupts if db is read only (#251)
(It works for SUSE because we always open with DB_PRIVATE and thus don't use the dbenv at all. So there's no ignorant denial involved ;-) ) -- 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-315322064___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Don't modify interupts if db is read only (#251)
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___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Don't modify interupts if db is read only (#251)
Ok i'll update the commit message as a starting point, the original patch was quite different but it doesn't seem like this has been covered in the latest version. -- 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-315049665___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Don't modify interupts if db is read only (#251)
It's done so that ^C exists rpm if in read-only mode. I don't know how it interacts with the db-env, SUSE only uses DB_PRIVATE. Panu also changed the signal handling quite a bit recently, so it may well be that the patch is no longer needed. -- 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-315048249___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Don't modify interupts if db is read only (#251)
I would be happy if commit message was explaining problem... Though code looks good -- 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-315022545___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
