Description of problem: After register and subscribe for the system, the cmd "repos --list --proxy" with a fake proxy server url will not stop running. Version-Release number of selected component (if applicable): subscription-manager-1.8.8-1.el5 subscription-manager-gui-1.8.8-1.el5 subscription-manager-firstboot-1.8.8-1.el5 python-rhsm-1.8.11-1.el5 How reproducible: always Steps to Reproduce: 1.Register the system and subscribe some subscriptions 2.Run command below: #subscription-manager repos --list --proxy=www.baidu.com notice that "www.baidu.com" is a real url but not the porxy server. Actual results: There is no output, the cmd runs on and on. Expected results: The output should come out for a short time, and looks like below: Network error, unable to connect to server. Please see /var/log/rhsm/rhsm.log for more information. Additional info: The expect results will come whe use a string as a url like: #subscription-manager repos --list --proxy=www It seems that the there no limit times that rhsm would try to reconnect the porxy server.
Created attachment 754637 [details] rhsm log when error happens
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.
Re-testing with version... [root@jsefler-5 ~]# rpm -q subscription-manager subscription-manager-1.8.10-1.git.53.5b88475.el5 The scenario in comment 0 is sort-of working. The user wasn't patient enough to wait 12 real time minutes for a network timeout to occur. Despite the 12 minutes that I had to wait for the CLI command to complete, rhsm.log reported several "timed out" tracebacks at 2 minute intervals. [root@jsefler-5 ~]# time subscription-manager repos --list --proxy=www.baidu.com Network error, unable to connect to server. Please see /var/log/rhsm/rhsm.log for more information. real 12m2.839s user 0m0.733s sys 0m0.240s [root@jsefler-5 ~]# echo $? 255 [root@jsefler-5 ~]# [root@jsefler-5 ~]# tail -f /var/log/rhsm/rhsm.log 2013-06-19 10:46:35,183 [DEBUG] @connection.py:400 - Using proxy: www.baidu.com:3128 2013-06-19 10:46:35,183 [DEBUG] @connection.py:415 - Making request: GET https://jsefler-f14-candlepin.usersys.redhat.com:8443/candlepin/consumers/c13fb277-3a3b-49b7-86e3-fc508553e220/release 2013-06-19 10:48:35,190 [WARNING] @certmgr.py:107 - Exception caught while running <subscription_manager.repolib.RepoLib object at 0x19505d10> update 2013-06-19 10:48:35,191 [ERROR] @certmgr.py:108 - timed out Traceback (most recent call last): File "/usr/share/rhsm/subscription_manager/certmgr.py", line 100, in update updates += lib.update() File "/usr/share/rhsm/subscription_manager/certlib.py", line 69, in update return self._do_update() File "/usr/share/rhsm/subscription_manager/repolib.py", line 43, in _do_update action = UpdateAction(uep=self.uep) File "/usr/share/rhsm/subscription_manager/repolib.py", line 108, in __init__ result = self.uep.getRelease(self.consumer_uuid) File "/usr/lib64/python2.4/site-packages/rhsm/connection.py", line 920, in getRelease results = self.conn.request_get(method) File "/usr/lib64/python2.4/site-packages/rhsm/connection.py", line 481, in request_get return self._request("GET", method) File "/usr/lib64/python2.4/site-packages/rhsm/connection.py", line 422, in _request conn.request(request_type, handler, body=body, headers=headers) File "/usr/lib64/python2.4/httplib.py", line 810, in request self._send_request(method, url, body, headers) File "/usr/lib64/python2.4/httplib.py", line 833, in _send_request self.endheaders() File "/usr/lib64/python2.4/site-packages/rhsm/connection.py", line 174, in endheaders httpslib.HTTPSConnection.endheaders(self) File "/usr/lib64/python2.4/httplib.py", line 804, in endheaders self._send_output() File "/usr/lib64/python2.4/httplib.py", line 685, in _send_output self.send(msg) File "/usr/lib64/python2.4/httplib.py", line 652, in send self.connect() File "/usr/lib64/python2.4/site-packages/M2Crypto/httpslib.py", line 175, in connect HTTPConnection.connect(self) File "/usr/lib64/python2.4/httplib.py", line 636, in connect raise socket.error, msg timeout: timed out
The example 'baidu.com' resolves and we timeout waiting for it to respond, which it never does (it doesn't respond at all). And the RHEL5 socket timeouts are longish (two minutes). It multiples this by each connection it tries to make (certmgr.py and friends will all fail). This intentionly continue on network exceptions (or any exception really) since they are indepedent and each certmgr module should be run in order. We could potentially special case timeouts here (Similar behaviour can be induced sans proxy as well, if the server URL is pointed to a server with the same behaviour). We could potentially mitigate this with either: - shorter timeout - on timeout, exit more forcefully (instead of catching the network exception on the server version check network call, we would raise the timeout exception and exit if we got it. We could maybe just do this on cli invocation A pr for the latter is at https://github.com/candlepin/subscription-manager/pull/711
in master: commit 7cd74169e0ea80894218fcc605f5c705d050b6e1 Author: Adrian Likins <alikins> Date: Mon Jul 22 18:37:50 2013 -0400 968820: raise timeout exceptions for cli calls If we get a socket.timeout doing the initial server resource check from the cli, assume all network connections are going to fail on a timeout, so to prevent waiting minutes for that to finish, raise the exception so we exit quicker.
[root@localhost ~]# time subscription-manager repos --list --proxy=www.baidu.com Network error, unable to connect to server. Please see /var/log/rhsm/rhsm.log for more information. real 2m0.309s user 0m0.255s sys 0m0.053s Though 2minite still a little long for the client, I'll change the status to verified. Verified on RHEL5.10-sp3-server64 with subscription-manager version 1.8.15-1
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-2013-1332.html