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:
When registering, unregistering, and (likely) binding, entitlement, product, and identity certificates are re-read many times over, and the GUI is refreshed repeatedly.
Version-Release number of selected component (if applicable):
subscription-manager-0.96.3-1
How reproducible:
Very.
Steps to Reproduce:
1. tail -f /var/log/rhsm/rhsm.log
2. Unregister from a server.
Actual results:
In the rhsm.log output you will see *multiple* instances of:
2011-07-11 14:27:03,042 [DEBUG] @certlib.py:675 - Sorting product and entitlement cert status for: 2011-07-11 14:27:03.042224
2011-07-11 14:27:03,043 [DEBUG] @certlib.py:693 - Installed product IDs: ['37060']
2011-07-11 14:27:03,044 [DEBUG] @certlib.py:684 - valid entitled products: []
2011-07-11 14:27:03,044 [DEBUG] @certlib.py:685 - expired entitled products: []
Expected results:
This should happen just once, or at least as little as possible.
Additional info:
These appear to all be triggering via the managergui.py MainWindow.refresh method.
I believe this is related to the Backend classes file monitors. We monitor directories, I suspect the monitors are triggering once per file change. i.e. if we unregister, the identity cert, key, and their directory all get deleted, suspect this is triggering 3x refreshes right here.
Secondly, the file monitors catch changes that are also dealt with explicitly in the code. For example, managergui.py _on_unregister_prompt_response method calls refresh explicitly, but the unregistration is also caught by the identity certificate file monitor. The same goes for registration refresh.
I suspect if you have a number of entitlement certificates and unregister, you'll get additional GUI refreshes if you unregister and they all get removed.
Marked as low priority because, while this is messy and strange, the UI still seems acceptably responsive. It should get fixed eventually however.
Proposed fix:
If possible, we should get the file monitors to only trigger once, perhaps monitoring the identity cert itself instead of the directory it lives in.
Secondly we should examine calls to refresh() in managergui, and eliminate those that are duplicated by the monitors for identity and entitlement certificates. (let the file monitors trigger the refreshes)
Another possible culprit, rather than the file monitors triggering for every change to any file in the dir (just a guess), it could perhaps be multiple Backend objects floating around, all triggering their own file monitors.
After changing the file monitor to use the polling implementation, GUI refreshes are kept to a minimum as the monitor seems to emit the correct number of changes.
Committed to master branch: e7eae1b8f16dc943f32876448fcd5f28be8434d3
This should address the slowness that QA have been seeing when doing an auto subscribe with a lot of products, as well as cut down on some of the multiple GUI refreshes.
i.e sudo subscription-manager subscribe --auto
That being said, we should still look at trying to minimize the number of ways that the GUI is being refreshed (see Proposed Fix above).
In light of this, I am lowering the priority of this bug, and moving it back to new so that it can be addressed at some other point. At this point I don't think it is a show stopper.
I have verified that this is no longer a blocker, the gui now completes the refresh in a reasonable amount of time as of versions:
subscription-manager-gnome-0.96.4-1.git.47.e65faae.el6.x86_64
subscription-manager-0.96.4-1.git.47.e65faae.el6.x86_64
subscription-manager-firstboot-0.96.4-1.git.47.e65faae.el6.x86_64
python-rhsm-0.96.7-1.git.4.ae2c338.el6.noarch
I am leaving the status as NEW as per comment 6 .
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
http://rhn.redhat.com/errata/RHBA-2011-1695.html