Bug 1130764 - rollback during yum downgrade fails in case of <Ctrl>C [NEEDINFO]
Summary: rollback during yum downgrade fails in case of <Ctrl>C
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: otopi
Classification: oVirt
Component: Plugins.packagers
Version: 1.0.0
Hardware: Unspecified
OS: Unspecified
medium
medium vote
Target Milestone: ovirt-4.1.1
: ---
Assignee: Yedidyah Bar David
QA Contact: movciari
URL:
Whiteboard:
: 1139225 1304613 1304658 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-08-17 12:56 UTC by Yedidyah Bar David
Modified: 2017-02-06 10:27 UTC (History)
14 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-02-06 10:27:35 UTC
oVirt Team: Integration
sbonazzo: needinfo? (didi)
rule-engine: ovirt-4.1+


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Bugzilla 1274220 None CLOSED Setup can't be canceled using Ctrl + C when setting Local ISO domain path 2019-09-16 15:43:03 UTC

Internal Links: 1274220

Description Yedidyah Bar David 2014-08-17 12:56:29 UTC
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).

Comment 4 Sandro Bonazzola 2014-08-18 14:09:09 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.

Comment 5 Alon Bar-Lev 2014-08-18 15:27:29 UTC
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.

Comment 6 Sandro Bonazzola 2014-08-19 13:35:10 UTC
(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?

Comment 7 Alon Bar-Lev 2014-08-19 13:39:00 UTC
> 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.

Comment 8 Alon Bar-Lev 2014-08-19 15:05:28 UTC
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.

Comment 9 Alon Bar-Lev 2014-08-20 19:38:34 UTC
Removing dev-ack, as was placed without authorization.

Comment 11 Yedidyah Bar David 2014-09-09 12:01:03 UTC
*** Bug 1139225 has been marked as a duplicate of this bug. ***

Comment 12 Yedidyah Bar David 2014-09-09 13:47:20 UTC
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.

Comment 13 Alon Bar-Lev 2015-01-13 10:33:57 UTC
 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-.

Comment 14 RHEL Product and Program Management 2015-01-13 10:45:49 UTC
Development Management has reviewed and declined this request.
You may appeal this decision by reopening this request.

Comment 15 Yedidyah Bar David 2015-01-13 13:36:27 UTC
(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 :-)

Comment 18 Yaniv Lavi 2016-02-04 13:52:59 UTC
*** Bug 1304613 has been marked as a duplicate of this bug. ***

Comment 19 Yaniv Lavi 2016-02-10 08:00:29 UTC
*** Bug 1304658 has been marked as a duplicate of this bug. ***

Comment 20 Sandro Bonazzola 2016-02-23 09:10:32 UTC
Not blocking bug #1285700 since this has been targeted to 4.0.

Comment 21 Sandro Bonazzola 2016-09-01 06:49:18 UTC
Can you check if this is still an issue?

Comment 22 Yaniv Lavi 2017-02-06 10:27:35 UTC
This doesn't seem to happen to users and the fix is complex, so closing until someone needs this.


Note You need to log in before you can comment on or make changes to this bug.