Created attachment 486039 [details] pup crash dump Description of problem: The update tool (pup) failed during this morning's update. I have attached the crash dump. Version-Release number of selected component (if applicable): 3.2.22 How reproducible: Not reproducible on my system -- pup now reports that there are no new updates available. Steps to Reproduce: 1. Click Apply Updates button in the Package Updater. 2. 3. Actual results: Package updater retrieves packages, installs them, and fails at what appears to be near the end of the cleanup phase. Expected results: successful completion without a crash :) Additional info: I have attached the crash "dump" from pup.
File "/usr/lib/python2.4/site-packages/rhn/transports.py", line 704, in send_http headers=self.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/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 664, in send self.sock.sendall(str) File "/usr/lib/python2.4/site-packages/rhn/SSL.py", line 217, in write sent = self._connection.send(data) SysCallError: (104, 'Connection reset by peer') ...we can't really do anything above the rhn layer, as we aren't expecting to hit the network in posttrans (plus we'd have no idea what to do). I guess you probably want to retry, and/or ignore.
Is an application crash accompanied by a largely incomprehensible crash dump and the message to the effect that "something bad happened. Probably a bug. Please file a bug report" the expected and/or desired behavior when this app encounters a lost TCP/IP connection?
Does this problem still show? Although judging by the error message: SysCallError: (104, 'Connection reset by peer') I doubt this really is a bug in rhn-client-tools / rhnlib / yum-rhn-plugin code. It seems more like a network connection / line problem.
I would say this is valid BZ. We should catch all exception and re-raise them is YumBaseError - or some Exception which inherit from YumBaseError, then pulp - or yum or whoever. Should do its best to corectly behave (and they do). But they simply do not expect from plugin anything then YumBaseError. Although this is not material for RHEL5.8 as the original problem is definitely temporary network error and the fix is only not showing user traceback, but some nice error message. I'm going to close this BZ, but will clone it for RHEL6.