Bug 1419723
| Summary: | Exception TypeError: "'NoneType' object is not callable" in <function _removeHandlerRef at 0x237c050> ignored on every vbmc command | ||
|---|---|---|---|
| Product: | Red Hat OpenStack | Reporter: | Dan Yasny <dyasny> |
| Component: | python-virtualbmc | Assignee: | Ilya Etingof <ietingof> |
| Status: | CLOSED DUPLICATE | QA Contact: | Dan Yasny <dyasny> |
| Severity: | low | Docs Contact: | |
| Priority: | low | ||
| Version: | 11.0 (Ocata) | CC: | athomas, derli, dtantsur, dyasny, vcojot |
| Target Milestone: | --- | Keywords: | Triaged |
| Target Release: | 11.0 (Ocata) | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2017-11-10 16:25:45 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Dan Yasny
2017-02-06 21:24:36 UTC
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 *** |