Since upgrading to RHEL5.1, I have been seeing these occasionally in my log files: Nov 12 15:39:29 XXXXX yum-updatesd: error getting update info: local variable 'result' referenced before assignment Looking at the source code, it is not clear to me where this could be happening. Sorry that I am not of much more help. Since the RHEL5.1 update, it has happened only a few times on each machine. Must be due to some transient failure with RHN or the local network? Thought I would bz it regardless. thanks!
Created attachment 259841 [details] Python traceback While doing random machine install of a package, I got a traceback!
Is this RHN (rhn.redhat.com) or RHN Satellite registered system?
Hi Jan, RHN hosted via a proxy. daryl
Created attachment 262481 [details] python traceback trying to use yum Getting errors here too. RHEL 5.1 behind a local RHN proxy.
Jan, I'm seeing these errors on all my 5.1 systems. Some use a proxy and others don't but all are hosted.
I just switched the machine I was playing with off our proxy onto the central RHN server, and I'm still getting this error, so I can confirm it's not limited to proxy.
ok, so troubleshooting this on IRC (#rhel on freenode), the following seems to clear this up: 1) on the proxy server: a) add "range_offset_limit -1 KB" to /etc/squid/squid.conf b) service rhn-proxy stop c) rm -rf /var/spool/squid/* d) service rhn-proxy start 2) on the affected machines: a) yum clean all step 2 is what I missed when testing the previously-on-proxy machine on hosted. So I have a workaround that gets my machines working again, but something in the RHEL 5.1 update apparently caused this. I've got RHN Proxy 4.2.2. Did it need to be updated to handle 5.1?
Just so that everyone is clear the above fix corrects a known problem that persistently causes the python traceback but it does not relate in any way I know to the original bz problem described in this bug. I still see apparently random occurrences of this traceback on both systems talking directly to RHN and on systems going through an RHN proxy server.
*** Bug 384071 has been marked as a duplicate of this bug. ***
*** Bug 372811 has been marked as a duplicate of this bug. ***
*** Bug 370151 has been marked as a duplicate of this bug. ***
*** Bug 375151 has been marked as a duplicate of this bug. ***
Committed in rev 134216. Modified code such that if an URLGrab exception is received when trying to grab a file, the next mirror is tried. If all mirrors are exhausted, then the last exception thrown is raised. If it is not a URLGrab exception being thrown, then it is not caught by the problematic function, but by the calling function. (For example if ctrl-c is hit). For these cases, the next mirrors are not tried.
QE ack for RHEL5.2.
*** Bug 407061 has been marked as a duplicate of this bug. ***
Created attachment 277141 [details] this is traceback of system-config-packages command I'm using yum under proxy internet connection, i have two node cluster registered and cannot upgrade system software via rhn.
Created attachment 281351 [details] Test package with fix non-supported, non-signed test package
This package resolved the "duplicate messages" bug mentioned in bz #415801 , I'll let it run for a while and see if the "result" bug mentioned here is now fixed as well. thanks!
Created attachment 282541 [details] traceback of system-config-packages After apply upgrade of new yum-rhn-plugin still doesn't work; I'm behind http squid proxy to reach rhn.
(In reply to comment #23) > Created an attachment (id=282541) [edit] > traceback of system-config-packages > > After apply upgrade of new yum-rhn-plugin still doesn't work; I'm behind http > squid proxy to reach rhn. The problem you are seeing now is an SSL/Connection issue that is separate from the problem reported in this bug. The only reason you would have seen this "result" error is if you were having a 2nd connection issue that this was covering up. This bug merely concealed a connection problem (and it's backtrace). Now that it is fixed, you are seeing the true cause of your connection problem. I recommend you contact support about your SSL issue. Thanks! -Justin
*** Bug 419541 has been marked as a duplicate of this bug. ***
*** Bug 426381 has been marked as a duplicate of this bug. ***
*** Bug 426544 has been marked as a duplicate of this bug. ***
*** Bug 427848 has been marked as a duplicate of this bug. ***
*** Bug 352641 has been marked as a duplicate of this bug. ***
Will an errata be pushed for this regression? The big problem is that when the bug hits during errata install, it will cause the errata install to fail and yum won't retry the failed action. Example: https://rhn.redhat.com/network/systems/details/history/event.pxt?sid=1006860625&hid=153352961 This action's status is: Failed. The client picked up this action on 2008-01-11 06:43:17 CST. The client completed this action on 2008-01-11 06:43:52 CST. Client execution returned "Fatal error in Python code occured [[6]]" (code -1) On the system itself, you get the traceback from this bug's error. Glancing at this bug's history, it is not clear redhat understands that this bug will cause errata application to fail thus leaving systems vulnerable. thanks!
*** Bug 360031 has been marked as a duplicate of this bug. ***
hi guys, after searching for exactly the same problem, I found this bz. It's exactly the same problem as I have, and I have tried the patch, but it didn't resolve anything. Still got the same error: Client execution returned "Fatal error in Python code occured [[6]]" (code -1) Could someone please help me along with this?
Created attachment 291590 [details] logfile of rhn_check after installing the non-verified patch I still cannot run rhn_check. This attachment of the rhn_check -v that I ran.
(In reply to comment #44) > Created an attachment (id=291590) [edit] > logfile of rhn_check > > after installing the non-verified patch I still cannot run rhn_check. This > attachment of the rhn_check -v that I ran. Aj, The fact you are seeing the new error means that the patch worked correctly and you are seeing a 2nd issue. Try running 'yum clean all' and then try updating again. -Justin
At a customer site we have experienced the same problem caused by a BlueCoat contentfilter. We suspect that the BlueCoat is doing something man-in-the-middle that breaks SSL in peculiar ways. Besides having this bug in the code, the patch did not fix the real issue that triggers this bug. Our work-around was to disable SSL (or the https) connection the way that up2date used to do in the past. To do this, go into the file: /etc/sysconfig/rhn/up2date and change the entry: serverURL=https://xmlrpc.rhn.redhat.com/XMLRPC into: serverURL=http://xmlrpc.rhn.redhat.com/XMLRPC This will effectively disable the SSL connection. Beware however that you are susceptible for man-in-the-middle attacks and even though the RPM packages are signed, people could be feeding you different Red Hat signed packages than you would expect or something :-) Let me know if this works for you as well.
*** Bug 426261 has been marked as a duplicate of this bug. ***
Created attachment 295546 [details] yum update fails 'local variable 'result' referenced before assignment'
*** Bug 416271 has been marked as a duplicate of this bug. ***
*** Bug 432099 has been marked as a duplicate of this bug. ***
Just so everyone is clear, this has been released as an Async errata and is available (fully supported) here: https://rhn.redhat.com/rhn/errata/details/Details.do?eid=6568
Created attachment 302436 [details] traceback error Behind BluCoat :After change up2date file and substitute https with http still doesn't work
Hi Justin, I am probably missing something, but why is this bug still open and in ON_QA state? Can't it be closed? thanks, daryl
Daryl, this bug is still being tested by QE. It should be verified and closed very soon.
I have only ever seen this bug when trying to communicate with an RHN server that was broken. I saw the error again last week, but could not reproduce it. Is there a definitive way to reproduce this error?
*** Bug 443784 has been marked as a duplicate of this bug. ***
Cameron, The error would occur whenever there was a communication error with rhn. One way to reproduce is to hit ctrl-c in the middle of a package transfer, or use the wrong SSL CA Certificate when connecting to hosted or a sat. -Justin
Daryl, Sadly this bz can't be closed yet since 5.2 hasn't been released. It should be closed upon 5.2's release. -Justin
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2008-0360.html
*** Bug 426190 has been marked as a duplicate of this bug. ***
*** Bug 421051 has been marked as a duplicate of this bug. ***
*** Bug 413591 has been marked as a duplicate of this bug. ***
*** Bug 420671 has been marked as a duplicate of this bug. ***
*** Bug 586531 has been marked as a duplicate of this bug. ***