Bug 1419723 - Exception TypeError: "'NoneType' object is not callable" in <function _removeHandlerRef at 0x237c050> ignored on every vbmc command
Summary: Exception TypeError: "'NoneType' object is not callable" in <function _remove...
Keywords:
Status: CLOSED DUPLICATE of bug 1473276
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: python-virtualbmc
Version: 11.0 (Ocata)
Hardware: x86_64
OS: Linux
low
low
Target Milestone: ---
: 11.0 (Ocata)
Assignee: Ilya Etingof
QA Contact: Dan Yasny
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-02-06 21:24 UTC by Dan Yasny
Modified: 2018-03-05 23:10 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-11-10 16:25:45 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Dan Yasny 2017-02-06 21:24:36 UTC
Description of problem:
Exception TypeError: "'NoneType' object is not callable" in <function _removeHandlerRef at 0x237c050> ignored is returned by vbmc when any command is typed in. Seems to be purely cosmetical since vbmc is working despite the error message

Version-Release number of selected component (if applicable):
python-virtualbmc.noarch 0:0.1.1-0.20161216115645.bd3fca1.el7ost

How reproducible:
always

Steps to Reproduce:
1. install python-virtualbmc in rhel 7.3 from the OSP11 puddle
2. run any vbmc command
3.

Actual results:
as above

Expected results:
no errors

Additional info:

Comment 1 Derek Li 2017-10-16 09:20:44 UTC
Encounter exactly the same error when trying to set up a test environment using a virtual controller.
Env: latest RHEL 7.4, OSP11

Comment 2 Dmitry Tantsur 2017-10-20 11:40:06 UTC
I can confirm this still happening as well. Ilya, wanna take a look since Lucas left?

Comment 3 Dmitry Tantsur 2017-10-20 11:41:23 UTC
Just to clarify: it happened to me on a clean (more or less) system with only python-virtualbmc, python-pyghmi and python-setuptools (due to bug in pbr) installed:

$ vbmc list
+-------------+--------+---------+------+
| Domain name | Status | Address | Port |
+-------------+--------+---------+------+
+-------------+--------+---------+------+
Exception TypeError: "'NoneType' object is not callable" in <function _removeHandlerRef at 0x1e2c758> ignored

I haven't seen it on my Pike quickstart installation.

$ rpm -q python-virtualbmc
python-virtualbmc-1.0.0-3.el7ost.noarch
$ rpm -q python-pyghmi
python-pyghmi-1.0.12-1.el7ost.noarch

Comment 4 Ilya Etingof 2017-10-31 18:52:58 UTC
OK, here is my Halloween analysis for your reading scare.

This particular issue seems to be related to the stdlib/logging.py module's shutdown: multiple threads are trying to concurrently cease logging.py's internals and some fail semi-randomly.

Upstream has tried to harden logging.py code [1], however that is still not an ultimate fix because Python < 3.4 shutdown is haunted [2].

Just like a regular Halloween prank, the *subj* exception is annoying but otherwise harmless.

We could partially relieve this annoyance by postponing [3] pyghmi initialization (the cause of multiple threads) till the moment when we really need pyghmi's services. By that point we are risking the same error to come up on vbmc termination.

Alternatively, we could avoid the problem by not calling the shutdown hooks (by exiting via os._exit()). That's probably more risky in the end.

To me, the best solution would be to merge and switch the re-designed virtualbmc  version [4] which has pyghmi isolated to the daemon (vbmcd) effectively making the UI tool (vbmc) single-threaded and thus hopefully not affected to all this horror mess.

1. https://bugs.python.org/issue21149
2. https://hg.python.org/cpython/file/v2.7.13/Objects/moduleobject.c#l102
3. https://github.com/openstack/virtualbmc/blob/master/virtualbmc/cmd/vbmc.py#L22
4. https://review.openstack.org/#/c/488874/

Comment 5 Ilya Etingof 2017-11-10 16:25:45 UTC

*** This bug has been marked as a duplicate of bug 1473276 ***


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