Description of problem: If engine-setup had to install a package and we later fail, during rollback it tries to remove it but fails in the middle. Version-Release number of selected component (if applicable): Not sure, happened to me on 3.4.2 (current latest_av anyway). How reproducible: Not completely sure Steps to Reproduce: 1. yum install rhevm rhevm-dwh-setup 2. engine-setup 3. choose to configure dwh 4. after the rhevm-dwh package is installed, e.g. during "Creating PostgreSQL 'engine' database", press ^C Actual results: engine-setup crashes without writing anything significant to the log file or output. End of log in a specific case: 2014-08-15 16:20:10 ERROR otopi.context context._executeMethod:161 Failed to execute stage 'Misc configuration': Command '/sbin/service' failed to execute 2014-08-15 16:20:10 DEBUG otopi.transaction transaction.abort:131 aborting 'Yum Transaction' 2014-08-15 16:20:10 INFO otopi.plugins.otopi.packagers.yumpackager yumpackager.info:92 Yum Performing yum transaction rollback Expected results: rollback finishes successfully Additional info: Added some debug prints to yum and did not manage to find root cause yet. It fails when calling the function _search in rpmsack.py, while calling readOnlyTS . Now tried this also in 3.3 - it fails too in the same way. To reproduce, installed 3.3.3 (is36.5), added latest_is, updated rhevm-setup, ran engine-setup, and killed it ^C while it created the database (after updating the packages to 3.3.4).
As far as I can see, it fails while otopi-1.2.2 executes: /usr/lib/python2.6/site-packages/otopi/miniyum.py:775 if self._yb.history_undo(transactionCurrent): the python interpreter exit with code 1, no more output, no stack traces, no core dumps. However, if instead of hitting ctrl-c I raise an error inside the code with just "raise Exception('false error')" the transaction is correctly rolled back. So I think this is an event masking issue, not masking the ctrl-c for the yum module. This should be handled by otopi. I also don't think this is an urgent issue to be fixed, but maybe wirth a kb article while the issue is still open.
but our ctrl-c hook does raise an exception, so maybe I did not understand what you mean by you raising an exception... I suspect yum install its own hook for ctrl-c and this is why it behaves this way. I would like to find a way to totally ignore ctrl-c.
(In reply to Alon Bar-Lev from comment #5) > but our ctrl-c hook does raise an exception, so maybe I did not understand > what you mean by you raising an exception... I mean totally avoid hitting ctrl-c and raise any other kind of exception in the code causing the yum rollback > > I suspect yum install its own hook for ctrl-c and this is why it behaves > this way. I would like to find a way to totally ignore ctrl-c. Make sense. Any idea on how to do that?
> Make sense. Any idea on how to do that? no, we have limitations of what we can do with yum without touching its code. maybe the successor of yum will provide a better service in this regard.
this is probably deep down within rpm-python::_rpmmodule.so::signalCaught one quick test... please try to add at otopi/main.py after signal.signal the following to ignore SIGINT: signal.signal(signal.SIGINT, lambda signum: pass) maybe the native rpm code cannot handle the exception properly, although I think that python is not getting control.
Removing dev-ack, as was placed without authorization.
*** Bug 1139225 has been marked as a duplicate of this bug. ***
BTW, suppose that QE will want to automatically verify that engine-setup rollback works well by making it fail at various points, we might want to think of a method to do that other than sending signals, as long as this bug is not solved.
Yaniv Dary 2015-01-13 05:31:25 EST Flags: pm_ack? → pm_ack+ are you pm? nice! not sure how you mark pm_ack when there is no dev_ack. for visibility setting dev_ack-.
Development Management has reviewed and declined this request. You may appeal this decision by reopening this request.
(In reply to RHEL Product and Program Management from comment #14) > Development Management has reviewed and declined this request. > You may appeal this decision by reopening this request. I appeal, then :-)
*** Bug 1304613 has been marked as a duplicate of this bug. ***
*** Bug 1304658 has been marked as a duplicate of this bug. ***
Not blocking bug #1285700 since this has been targeted to 4.0.
Can you check if this is still an issue?
This doesn't seem to happen to users and the fix is complex, so closing until someone needs this.