Bug 1130764
| Summary: | rollback during yum downgrade fails in case of <Ctrl>C | ||
|---|---|---|---|
| Product: | [oVirt] otopi | Reporter: | Yedidyah Bar David <didi> |
| Component: | Plugins.packagers | Assignee: | Yedidyah Bar David <didi> |
| Status: | CLOSED WONTFIX | QA Contact: | movciari |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 1.0.0 | CC: | bazulay, bugs, didi, dougsland, gklein, oourfali, pmatyas, pstehlik, rbalakri, Rhev-m-bugs, sbonazzo, srevivo, ykaul, ylavi |
| Target Milestone: | --- | Keywords: | Reopened |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2017-02-06 10:27:35 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | Integration | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Yedidyah Bar David
2014-08-17 12:56:29 UTC
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. |