Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
During the course of automated tests, the gui locks up completely and throws a traceback about dbus to the console.
Version-Release number of selected component (if applicable):
subscription-manager-1.10.3-1.git.1.4b7116f.el7.x86_64
subscription-manager-firstboot-1.10.3-1.git.1.4b7116f.el7.x86_64
python-rhsm-1.10.3-1.git.0.6ac2883.el7.x86_64
subscription-manager-migration-1.10.3-1.git.1.4b7116f.el7.x86_64
subscription-manager-migration-data-2.0.4-1.git.0.6bebf6f.el7.noarch
subscription-manager-gui-1.10.3-1.git.1.4b7116f.el7.x86_64
How reproducible:
??
Steps to Reproduce:
This happens during normal automated tests. It is hard to see what reproduces it as it seems to happen randomly (or maybe with an async delay) during tests involving subscribing and closing the GUI with the 'X' button - which is to say most of the automated tests.
Actual results:
The GUI locks up and gnome asks me if I want to force quit or close the program.
Then to the console you get this traceback:
GTK Accessibility Module initialized
GTK Accessibility Module initialized
GTK Accessibility Module initialized
** (-c:11873): WARNING **: AT-SPI: Error in GetItems, sender=org.freedesktop.DBus, error=The name :1.16 was not provided by any .service files
** (-c:11873): WARNING **: AT-SPI: Error in GetItems, sender=org.freedesktop.DBus, error=The name :1.17 was not provided by any .service files
GTK Accessibility Module initialized
** (-c:11873): WARNING **: AT-SPI: Error in GetItems, sender=(null), error=Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
ERROR:dbus.proxies:Introspect error on :1.74:/gui: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
subscription-manager-gui is already running
Traceback (most recent call last):
File "/sbin/subscription-manager-gui", line 170, in <module>
remote_object.show_window(dbus_interface=BUS_NAME)
File "/usr/lib/python2.7/site-packages/dbus/proxies.py", line 70, in __call__
return self._proxy_method(*args, **keywords)
File "/usr/lib/python2.7/site-packages/dbus/proxies.py", line 145, in __call__
**keywords)
File "/usr/lib/python2.7/site-packages/dbus/connection.py", line 651, in call_blocking
message, timeout)
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
Expected results:
No taceback, no locking up of GUI.
Additional info:
In an attempt to debug this, I have set the class __init__ function in dbus_interface.py to simply return (thus disabling dbus). This seems to avoid this lock up issue and automation runs successfully on tests that do not require dbus.
commit f9c4c1c514ed3dda2da57f80c443bbee18cf3ac2
Author: Adrian Likins <alikins>
Date: Wed Oct 16 17:26:31 2013 -0400
1017351: ignore dbus failures on show_window
If we get a dbus exception from what seems like
a working dbus session bus connection while attempting
to raise an existing subscription-manager-gui, now
ignore the error, and open another window. And log
some of the info, so we can track this down.
Getting into that scenario seems to only get triggered
from tests automation when using the at-spi framework.
This isn't a fix, but it should get tests working, and
more info.
Removing test block on this bug.
I don't see the dbus error anymore, but the locking up still seems to happen. I'm postponing verification of this bug to see where Bug 1002203 goes, which I believe to be the source of the rhsm lock ups.
Description of problem: During the course of automated tests, the gui locks up completely and throws a traceback about dbus to the console. Version-Release number of selected component (if applicable): subscription-manager-1.10.3-1.git.1.4b7116f.el7.x86_64 subscription-manager-firstboot-1.10.3-1.git.1.4b7116f.el7.x86_64 python-rhsm-1.10.3-1.git.0.6ac2883.el7.x86_64 subscription-manager-migration-1.10.3-1.git.1.4b7116f.el7.x86_64 subscription-manager-migration-data-2.0.4-1.git.0.6bebf6f.el7.noarch subscription-manager-gui-1.10.3-1.git.1.4b7116f.el7.x86_64 How reproducible: ?? Steps to Reproduce: This happens during normal automated tests. It is hard to see what reproduces it as it seems to happen randomly (or maybe with an async delay) during tests involving subscribing and closing the GUI with the 'X' button - which is to say most of the automated tests. Actual results: The GUI locks up and gnome asks me if I want to force quit or close the program. Then to the console you get this traceback: GTK Accessibility Module initialized GTK Accessibility Module initialized GTK Accessibility Module initialized ** (-c:11873): WARNING **: AT-SPI: Error in GetItems, sender=org.freedesktop.DBus, error=The name :1.16 was not provided by any .service files ** (-c:11873): WARNING **: AT-SPI: Error in GetItems, sender=org.freedesktop.DBus, error=The name :1.17 was not provided by any .service files GTK Accessibility Module initialized ** (-c:11873): WARNING **: AT-SPI: Error in GetItems, sender=(null), error=Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. ERROR:dbus.proxies:Introspect error on :1.74:/gui: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. subscription-manager-gui is already running Traceback (most recent call last): File "/sbin/subscription-manager-gui", line 170, in <module> remote_object.show_window(dbus_interface=BUS_NAME) File "/usr/lib/python2.7/site-packages/dbus/proxies.py", line 70, in __call__ return self._proxy_method(*args, **keywords) File "/usr/lib/python2.7/site-packages/dbus/proxies.py", line 145, in __call__ **keywords) File "/usr/lib/python2.7/site-packages/dbus/connection.py", line 651, in call_blocking message, timeout) dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. Expected results: No taceback, no locking up of GUI. Additional info: In an attempt to debug this, I have set the class __init__ function in dbus_interface.py to simply return (thus disabling dbus). This seems to avoid this lock up issue and automation runs successfully on tests that do not require dbus.