Bug 1149095

Summary: [abrt] yum: injectioninit.py:52:init_dep_injection:AttributeError: 'module' object has no attribute 'PROFILE_MANAGER'
Product: Red Hat Enterprise Linux 7 Reporter: David Jaša <djasa>
Component: subscription-managerAssignee: candlepin-bugs
Status: CLOSED ERRATA QA Contact: Sean Toner <stoner>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.1CC: alikins, bkearney, djasa, james.antill, ohudlick, stoner, vmukhame, wpoteat
Target Milestone: rc   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
Whiteboard: abrt_hash:ba19bcec6281bc484a40a4f8f5d016cedebe3c28
Fixed In Version: subscription-manager-1.14.6-1 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-11-19 11:48:11 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1121117    
Attachments:
Description Flags
File: backtrace
none
File: environ
none
File: sosreport.tar.xz
none
Attempt to reproduce yum update issue none

Description David Jaša 2014-10-03 08:31:46 UTC
Description of problem:
yum crashed at the end of the update, after "Verification" of all the packages. Following yum-check would run infinitely.

Version-Release number of selected component:
yum-3.4.3-122.el7

Additional info:
reporter:       libreport-2.1.11
cmdline:        /usr/bin/python /bin/yum update
dso_list:       subscription-manager-1.13.3-1.el7.x86_64
executable:     /bin/yum
kernel:         3.10.0-167.el7.x86_64
runlevel:       N 5
type:           Python
uid:            0

Truncated backtrace:
injectioninit.py:52:init_dep_injection:AttributeError: 'module' object has no attribute 'PROFILE_MANAGER'

Traceback (most recent call last):
  File "/bin/yum", line 29, in <module>
    yummain.user_main(sys.argv[1:], exit_code=True)
  File "/usr/share/yum-cli/yummain.py", line 367, in user_main
    errcode = main(args)
  File "/usr/share/yum-cli/yummain.py", line 273, in main
    return_code = base.doTransaction()
  File "/usr/share/yum-cli/cli.py", line 771, in doTransaction
    resultobject = self.runTransaction(cb=cb)
  File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 1881, in runTransaction
    self.plugins.run('posttrans')
  File "/usr/lib/python2.7/site-packages/yum/plugins.py", line 188, in run
    func(conduitcls(self, self.base, conf, **kwargs))
  File "/usr/lib/yum-plugins/product-id.py", line 57, in posttrans_hook
    conduit.error(3, str(e))
  File "/usr/share/rhsm/subscription_manager/injectioninit.py", line 52, in init_dep_injection
    inj.provide(inj.PROFILE_MANAGER, ProfileManager, singleton=True)
AttributeError: 'module' object has no attribute 'PROFILE_MANAGER'

Local variables in innermost frame:

Comment 1 David Jaša 2014-10-03 08:31:48 UTC
Created attachment 943642 [details]
File: backtrace

Comment 2 David Jaša 2014-10-03 08:31:49 UTC
Created attachment 943643 [details]
File: environ

Comment 3 David Jaša 2014-10-03 08:32:43 UTC
Created attachment 943644 [details]
File: sosreport.tar.xz

Comment 5 Adrian Likins 2014-10-31 16:31:14 UTC
Looks like the old yum product id plugin is running post transaction with the new subscription-manager code installed, and the plugin does a late import of
'injectioninit', gets the new injectioninit module, but
the old 'inj' module is already loaded in the yum process. And the old 'inj' module does not have inj.PROFILE_MANAGER


That will be interesting to fix.

Comment 6 Adrian Likins 2014-10-31 17:04:57 UTC
The existing deployed subman yum plugins end up loading subscription_manager.injection in the yum process

plugins/subscription-manager.py has:
from subscription_manager import injection as inj 

so 'injection' module already exists in the yum process (and has
had 'init_dep_injection()' run once by the config_hook in plugins/subscription-manager.py. 

The post_trans hook for product id (in the RHEL7 GA product-id.py) tries to import injectioninit again and run injectioninit.init_dep_injection() again, which seems to end up with the new injectioninit module and the old 'injection' module. Not sure why though.

Comment 7 Devan Goodwin 2014-11-04 14:21:13 UTC
*** Bug 1075669 has been marked as a duplicate of this bug. ***

Comment 9 William Poteat 2015-04-27 19:33:55 UTC
Please give a reproducer for the scenario. 

Is it an update to yum *and* subscription-manager through yum?

Comment 10 William Poteat 2015-04-27 19:35:39 UTC
Which yum plugins are enabled during this process?
Is there an entitlment attached?

Comment 13 Adrian Likins 2015-04-27 20:11:56 UTC
Looking at this again, and I don't think that injectioninit needs to be a lazy import any longer. If it's imported at module scope, productid should end up loading the pre transaction version of all the modules. 

I think the lazy import was to work around issues with having to wait until logging was setup properly which I don't believe is a problem anymore.

Comment 14 Adrian Likins 2015-04-29 16:44:31 UTC
pr at https://github.com/candlepin/subscription-manager/pull/1177

Comment 17 Sean Toner 2015-07-24 13:51:22 UTC
Created attachment 1055740 [details]
Attempt to reproduce yum update issue

On a RHEL 7.1 system, I did a downgrade from subman 1.13.22 to 1.10.14.  I then did a yum update back to the most recent subman available in the repo (1.13.22) which should still have exhibited the problem as I understood the problem.

Is there an actual reproduction step for this bug?

Comment 18 David Jaša 2015-07-24 15:16:14 UTC
I didn't try to reproduce - I just reported what I've seen back at the time. FWIW, I've disabled subscription-manager module since because I decided to use internal repos at some point of time and I didn't see it in other, RHN-connected - machines.

Comment 19 Sean Toner 2015-07-30 11:53:20 UTC
I tried doing a full `yum update` to update a RHEL 7.0 system because it should update from a broken package to another broken package:

...
---> Package subscription-manager.x86_64 0:1.10.14-7.el7 will be updated
---> Package subscription-manager.x86_64 0:1.13.22-1.el7 will be an update
...


However, this still succeeded.  So I am still unsure of how to reproduce this issue.  I dont know how to get the yum process in a state where sys.modules["injectioninit"] module still has references to the old definitions but a running script is trying to access the newer (upgraded) definition.

Comment 20 Sean Toner 2015-08-18 14:27:40 UTC
I have tried a scenario where I yum updated a "broken" (subscription-manager < 1.14.6-1) package to a newer package, and also even from broken package to broken package, and I did not come across this issue.

Looking at the code change, the move to not do a lazy import will mean that we should not run into a scenario where some symbols in the module refer to different versions in memory.

Comment 21 errata-xmlrpc 2015-11-19 11:48:11 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-2122.html

Comment 22 Red Hat Bugzilla 2023-09-14 02:48:32 UTC
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days