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]
While doing random machine install of a package, I got a traceback!
Is this RHN (rhn.redhat.com) or RHN Satellite registered system?
RHN hosted via a proxy.
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
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) 
> 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.
*** 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:
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 []" (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.
*** Bug 360031 has been marked as a duplicate of this bug. ***
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 []" (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) 
> 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.
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
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:
and change the entry:
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:
Created attachment 302436 [details]
Behind BluCoat :After change up2date file and substitute https with http still
I am probably missing something, but why is this bug still open and in ON_QA
state? Can't it be closed?
Daryl, this bug is still being tested by QE. It should be verified and closed
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. ***
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.
Sadly this bz can't be closed yet since 5.2 hasn't been released. It should be
closed upon 5.2's release.
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.
*** 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. ***