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:
Encounter exactly the same error when trying to set up a test environment using a virtual controller. Env: latest RHEL 7.4, OSP11
I can confirm this still happening as well. Ilya, wanna take a look since Lucas left?
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
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/
*** This bug has been marked as a duplicate of bug 1473276 ***