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.
Bug 671138 - subscription-manager tracebacks when receiving a 104 from candlepin
Summary: subscription-manager tracebacks when receiving a 104 from candlepin
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: subscription-manager
Version: 6.1
Hardware: Unspecified
OS: Unspecified
low
medium
Target Milestone: rc
: ---
Assignee: Bryan Kearney
QA Contact: John Sefler
URL:
Whiteboard:
Depends On:
Blocks: Entitlement-Beta
TreeView+ depends on / blocked
 
Reported: 2011-01-20 14:35 UTC by John Sefler
Modified: 2011-01-20 21:04 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-01-20 21:04:12 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description John Sefler 2011-01-20 14:35:34 UTC 
Description of problem:

Not sure what is causing this nor how to reproduce this, but currently while testing against the IT QA candlepin test environment, we are getting 104 errors and tracebacks.  If there is a way to catch this error on the client side and better recover from this error, that would be great.  Also important is that the IT environment not get in this state.


[root@jsefler-betaqa-1 ~]# grep hostname /etc/rhsm/rhsm.conf
# Server hostname:
hostname=subscriptions.rhn.webqa.redhat.com
proxy_hostname=

[root@jsefler-betaqa-1 ~]# subscription-manager register --username=jsefler-qabetauser-1 --password=redhat
(104, 'Connection reset by peer')



[root@jsefler-betaqa-1 ~]# tail -f /var/log/rhsm/rhsm.log
2011-01-20 07:48:51,053 [INFO] __init__() @connection.py:300 - Connection Established: host: subscriptions.rhn.webqa.redhat.com, port: 443, handler: /subscription
2011-01-20 07:48:51,142 [DEBUG] __init__() @certlib.py:649 - Sorting product and entitlement cert status for: 2011-01-20 07:48:51.141962
2011-01-20 07:48:51,158 [DEBUG] _populate_all_products() @certlib.py:667 - Installed product IDs: ['133', '132', '136', '135', '134']
2011-01-20 07:48:51,159 [DEBUG] __init__() @certlib.py:658 - valid entitled products: []
2011-01-20 07:48:51,159 [DEBUG] __init__() @certlib.py:659 - expired entitled products: []
2011-01-20 07:48:51,161 [INFO] _request() @connection.py:146 - loading ca pem certificates from: /etc/rhsm/ca/
2011-01-20 07:48:51,162 [INFO] _load_ca_certificates() @connection.py:133 - loading ca certificate '/etc/rhsm/ca/candlepin-stage.pem'
2011-01-20 07:48:51,163 [INFO] _load_ca_certificates() @connection.py:133 - loading ca certificate '/etc/rhsm/ca/fakamai-cp1.pem'
2011-01-20 07:48:51,163 [INFO] _load_ca_certificates() @connection.py:133 - loading ca certificate '/etc/rhsm/ca/redhat-uep.pem'
2011-01-20 07:48:51,164 [INFO] _request() @connection.py:148 - work in insecure mode ?:False
2011-01-20 07:49:15,691 [ERROR] handle_exception() @managercli.py:44 - Error during registration: (104, 'Connection reset by peer')
2011-01-20 07:49:15,692 [ERROR] handle_exception() @managercli.py:45 - (104, 'Connection reset by peer')
Traceback (most recent call last):
  File "/usr/share/rhsm/managercli.py", line 347, in _do_command
    facts=self.facts.get_facts())
  File "/usr/lib/python2.6/site-packages/rhsm/connection.py", line 322, in registerConsumer
    return self.conn.request_post('/consumers/', params)
  File "/usr/lib/python2.6/site-packages/rhsm/connection.py", line 202, in request_post
    return self._request("POST", method, params)
  File "/usr/lib/python2.6/site-packages/rhsm/connection.py", line 168, in _request
    headers=self.headers)
  File "/usr/lib64/python2.6/httplib.py", line 910, in request
    self._send_request(method, url, body, headers)
  File "/usr/lib64/python2.6/httplib.py", line 947, in _send_request
    self.endheaders()
  File "/usr/lib64/python2.6/httplib.py", line 904, in endheaders
    self._send_output()
  File "/usr/lib64/python2.6/httplib.py", line 776, in _send_output
    self.send(msg)
  File "/usr/lib64/python2.6/httplib.py", line 735, in send
    self.connect()
  File "/usr/lib64/python2.6/site-packages/M2Crypto/httpslib.py", line 50, in connect
    self.sock.connect((self.host, self.port))
  File "/usr/lib64/python2.6/site-packages/M2Crypto/SSL/Connection.py", line 185, in connect
    ret = self.connect_ssl()
  File "/usr/lib64/python2.6/site-packages/M2Crypto/SSL/Connection.py", line 178, in connect_ssl
    return m2.ssl_connect(self.ssl, self._timeout)
SSLError: (104, 'Connection reset by peer')
Comment 2 Jesus M. Rodriguez 2011-01-20 21:04:12 UTC 
This actually works as intended. The cli and gui both show the error but not the stack trace. The stack trace is limited to the log file which is intended. And since this is truly an exceptional case, the client handled this correctly.

I am closing this bug as NOTABUG.
Note You need to log in before you can comment on or make changes to this bug.