Hide Forgot
Description of problem: Sub-man-gui should be able to unregister a system once network is up again. Version-Release number of selected component (if applicable): Red Hat Enterprise Linux Workstation release 7.4 Beta (Maipo) ---------------------------- ---------------------------- arch x86_64 kernel version 3.10.0-663.el7.x86_64 ---------------------------- ---------------------------- server type Red Hat Subscription Management subscription management server 0.9.51.21-1 subscription management rules 5.15.1 subscription-manager 1.19.12-1.el7 python-rhsm 1.19.6-1.el7 ---------------------------- ---------------------------- Product 71.pem ---------------------------- ---------------------------- Entitlement 7608889971651551168.pem ---------------------------- ---------------------------- Steps to Reproduce: Given a system is registered and subscription-manager-gui is run and network is down When network is up again and I click 'Unregister' button Then the application should unregister the system. Actual results: The application raises an error message 'Network error. Unable to connect a server'. Expected results: The application should unregister the system. Additional info: It is similar to a case RHEL7-23897 RHSM-TC : Subscription-manager-gui : running instance of subscription-manager gui reads updated network details
I'm able to reproduce this bug.
The problem is deeper than I thought it will be. When you will run following simple C application using system call getaddrinfo(): https://gist.github.com/jirihnidek/bf7a2363e480491da72301b228b35d5d then you will notice same problem.
I was able to prove this bug can be fixed using calling res_init() adding to previous example. Look also at this: https://stackoverflow.com/questions/30360029/if-getaddrinfo-fails-once-it-fails-forever-even-after-network-is-ready The socket module does not have api for res_init(), but salt stack uses following hack: https://github.com/saltstack/salt/issues/21397
Cool, sub-man GUI has method reset_resolver() using ctypes and direct glibc res_init() in similar way as salt stack does it. Thus it is not so complicated to fix it.
Excelent! I am comping at the bit to automate this scenarion!
reproducing the failure on RHEL74 ==================================== subscription management server: 2.2.0-1 subscription management rules: 5.26 subscription-manager: 1.19.21-1.el7 python-rhsm: 1.19.9-1.el7 1) register client to candlepin 2) launch gui 3) stop network 4) try to unregister from GUI--> notice network error ( expected ) 5) start network service 6) Again try to unregister from GUI Observed an error message 'Network error. Unable to connect a server'. Verifying on RHEL75: =================== subscription-manager-rhsm-certificates-1.20.5-1.el7.x86_64 subscription-manager-gui-1.20.5-1.el7.x86_64 subscription-manager-rhsm-1.20.5-1.el7.x86_64 subscription-manager-1.20.5-1.el7.x86_64 subscription-manager-initial-setup-addon-1.20.5-1.el7.x86_64 subscription-manager-plugin-container-1.20.5-1.el7.x86_64 Followed the same steps , observed that system was unregistered from the GUI with out any network error. rhsm.log for reference: 2017-11-10 14:14:04,037 [INFO] subscription-manager-gui:15480:MainThread @managergui.py:497 - Unregister button pressed, asking for confirmation. 2017-11-10 14:14:06,158 [INFO] subscription-manager-gui:15480:MainThread @managergui.py:472 - Proceeding with un-registration: 6e2874e2-d592-4e93-b91f-d2eea484c968 2017-11-10 14:14:06,322 [INFO] subscription-manager-gui:15480:MainThread @connection.py:556 - Response: status=204, requestUuid=d32f3f7e-18e1-45ce-9f1a-4cbe26676140, request="DELETE /candlepin/consumers/6e2874e2-d592-4e93-b91f-d2eea484c968" 2017-11-10 14:14:06,323 [INFO] subscription-manager-gui:15480:MainThread @unregister.py:55 - Successfully un-registered. based on the above observations , marking the bug as "Verified"
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. https://access.redhat.com/errata/RHBA-2018:0681