Description of problem: Subscription-manager-gui throws traceback when launching the app immediately after closing it. The app is closed gracefully by hitting the close button. Version-Release number of selected component (if applicable): # rpm -qa | egrep "subscription-manager|python-rhsm" subscription-manager-1.8.4-1.git.31.00b0b78.el6.x86_64 subscription-manager-gui-1.8.4-1.git.31.00b0b78.el6.x86_64 python-rhsm-1.8.7-1.git.1.675a611.el6.x86_64 How reproducible: Always Steps to Reproduce: 1. Start subsscription-manager-gui app 2. Close it using the close "X" button. 3. Start it immediately after closing (we do this programatically in automation) Actual results: When the app is started again it creates a defunct process in the OS, but never shows up. GTK Accessibility Module initialized subscription-manager-gui is already running Traceback (most recent call last): File "/usr/sbin/subscription-manager-gui", line 163, in <module> remote_object.show_window(dbus_interface=BUS_NAME) File "/usr/lib/python2.6/site-packages/dbus/proxies.py", line 68, in __call__ return self._proxy_method(*args, **keywords) File "/usr/lib/python2.6/site-packages/dbus/proxies.py", line 140, in __call__ **keywords) File "/usr/lib/python2.6/site-packages/dbus/connection.py", line 630, in call_blocking message, timeout) dbus.exceptions.DBusException: org.freedesktop.DBus.Error.ServiceUnknown: The name :1.244 was not provided by any .service files Expected results: The application would launch without traceback. Additional info:
This bug affects many automation tasks (as the gui is restarted many times to 'reset' it). Another interesting thing to note is that the gui simply doesn't close cleanly: 1) run: subscription-manager-gui 2) run: ps -e | grep subscription - expected output like: 24410 pts/0 00:00:01 subscription-manager-gui 3) close the gui using the X button 4) run: ps -e | grep subscription - you will now get: 24410 pts/0 00:00:01 subscription-ma <defunct> This will tend to clean itself up if you wait a period of time before opening it again (the new process will remove the old defunct process), but in our automation scenario you will also get into this state: 26964 pts/0 00:00:01 subscription-ma <defunct> 27033 pts/0 00:00:00 subscription-ma <defunct> In any case, there is always a defunct process when the GUI closes, and this should ideally never happen.
reducing severity of this: it is difficult to reproduce manually and automation work-arounds are in place.
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux release for currently deployed products. This request is not yet committed for inclusion in a release.
This appears to be an automation bug. We cannot reproduce this error outside of a testing environment.