Bug 415801 - Incorrect server failover behavior
Incorrect server failover behavior
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: rhn-client-tools (Show other bugs)
5.1
All Linux
low Severity low
: ---
: ---
Assigned To: John Matthews
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-12-07 11:32 EST by John T. Rose
Modified: 2008-06-11 11:51 EDT (History)
0 users

See Also:
Fixed In Version: -0.5.3-6.el5_2.6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-06-11 11:51:19 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description John T. Rose 2007-12-07 11:32:04 EST
Description of problem:

I noticed on RHEL5 systems configured for server failover that we are seeing
duplicate channel metadata and headers downloaded (seem to be grabbed from each
failover server). Packages are only downloaded once if it gets that far in the
process.

Version-Release number of selected component (if applicable):

rhn-client-tools-0.4.16-2.el5_1.9

How reproducible:

Always

Steps to Reproduce:
1. Configure server failover as was done on all previous versions of RHEL
2. yum check-update (or other yum command)
  
Actual results:

# yum check-update
Loading "installonlyn" plugin
Loading "rhnplugin" plugin
Setting up repositories
rhel-i386-server-fastrack 100% |=========================| 1.2 kB    00:00     
rhel-i386-server-fastrack 100% |=========================| 1.2 kB    00:00     
rhel-i386-server-5        100% |=========================| 1.4 kB    00:00     
rhel-i386-server-5        100% |=========================| 1.4 kB    00:00     
rhel-i386-server-suppleme 100% |=========================| 1.4 kB    00:00     
rhel-i386-server-suppleme 100% |=========================| 1.4 kB    00:00     
rhel-i386-server-vt-5     100% |=========================| 1.4 kB    00:00     
rhel-i386-server-vt-5     100% |=========================| 1.4 kB    00:00     
rhn-tools-rhel-i386-serve 100% |=========================| 1.2 kB    00:00     
rhn-tools-rhel-i386-serve 100% |=========================| 1.2 kB    00:00     
Reading repository metadata in from local files

If there were any outstanding updates we would also see duplicate headers
downloaded from each server.

Expected results:

Process only the first server if it is available ...

# yum check-update
Loading "installonlyn" plugin
Loading "rhnplugin" plugin
Setting up repositories
rhel-i386-server-fastrack 100% |=========================| 1.2 kB    00:00     
rhel-i386-server-5        100% |=========================| 1.4 kB    00:00     
rhel-i386-server-suppleme 100% |=========================| 1.4 kB    00:00     
rhel-i386-server-vt-5     100% |=========================| 1.4 kB    00:00     
rhn-tools-rhel-i386-serve 100% |=========================| 1.2 kB    00:00     
Reading repository metadata in from local files

Additional info:

The cause of this issue is whether or not there exists a trailing semi-colon on
the end of the serverURL in /etc/sysconfig/rhn/up2date ... with the trailing
semi-colon as has always been the documented syntax you get the duplicates ...
without the trailing semi-colon you see the same behavior that previously
existed with the trailing semi-colon (the correct behavior).

Please consider fixing this so the configuration and behavior is once again
consistent across all RHEL versions. That is, allow the trailing semi-colon here
to work as it always has in the past.
Comment 1 John T. Rose 2007-12-07 12:00:31 EST
This bug as it turns out was noticed and fixed when working on bz 378911:
yum-updatesd: local variable 'result' referenced before assignment. We have
tested the fixed package provided there and have confirmed that it resolves this
issue. That is scheduled for 5.2 and since this issue doesn't have any dire
consequences (updates do get applied despite the duplicated work) this bz can be
closed.

Note You need to log in before you can comment on or make changes to this bug.