Red Hat Bugzilla – Bug 820295
Network Connection Checking in GUI
Last modified: 2014-02-04 09:45:08 EST
Description of problem:
This is probably an edge case, but if you lose your network connection while subscription-manager is open and try to use it, you'll get a failure, but when your network connection is back, it will continue to fail.
If you open subscription-manager with your network connection disabled, and try to download all your available subscriptions, it will fail, but when you enable it again, it will work (unlike above, where it will always give you a failure after).
If you run subscription-manager, lose your internet connection, but don't force a failure by trying to use it, and then try again when you have your connection, everything is fine.
All of this was with sub-man-gui, in the All Available Subscriptions tab, using the Update button on both versions below.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Disable your ethernet connection in your VM
2. Open Sub-Man, flip to All Available Subscriptions
3. Click Update, you get a failure dialog
4. Enable your network connection
5. Click Update, everything is fine now
6. Disable your ethernet connection
7. Click Update, you get a failure dialog
8. Enable your network connection
9. Click Update, you still get a failure
10. Click Update again in a bit, failure again
While sub-man seems to recover gracefully from starting with no internet connection and getting it back shortly after, I haven't gotten it to recognize my system regaining internet connectivity if it loses connection while already being open, and experiencing a failure.
I would expect subscription manager to realize that it had internet without having to close it and re-open it, just like it does in some cases already.
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
So on RHEL6 using network manager in the system tray, I'm not really able to reproduce.
Start with network disconnected, search for subs, get error. Enable network, search for subs, no problem. Disable while running, search, get slightly different but still accurate error. Re-enable, search, no problems.
Even with ifup/ifdown on eth0, the results are the same, it always recovers once I bring the interface back up. (regardless of what state it was in when I started it)
Could you clarify exactly how you were enabling/disabling the network?
Found a reproducer, needs to be using DNS to hit the server, where as I was using a local candlepin going directly to it's IP.
The error here is socket.gaierror: [ERROR] @utils.py:56 - [Errno -3] Temporary failure in name resolution
Even after bringing up the network connection, that error seemingly will never go away.
This problem is pretty widely reported in a number of programming languages and projects, I think it's well below our code in the socket libraries somehow. I can't find any solutions yet that don't end with restarting. For example, apache seems to sometimes have issues with this, I believe it is related to the fact that when a network interface comes back up, it could pick up new DNS servers, which confuses some already running programs. ( http://stackoverflow.com/questions/2880563/file-function-file-php-network-getaddresses-getaddrinfo-failed-temporary )
I made an attempt to re-instantiate the connections we hold onto in our code but this makes no difference, thus why I think the problem is well into lower levels. I honestly have no idea what we could do to solve. (and the error is already handled and reported to the user)
Given the rarity of the situation here (subscription manager opened while network was up, network interface taken down, network regained), I do not think this issue is worth pursuing. Restarting subscription-manager-gui in this rare situation, seems like an acceptable workaround.
Going to close, if anyone strongly disagrees let me know and we can figure out if we should re-open or what to do.
*** Bug 1061118 has been marked as a duplicate of this bug. ***