Bug 526450

Event posted on 09-17-2009 09:33am EDT by rmunilla

1. Time and date of problem:

Mon Sep 14 12:38:44 

2. System architecture(s):

x86_64

3. Provide a clear and concise problem description as it is understood at
the time of escalation. Please be as specific as possible in your
description. Do not use the generic term "hang", as that can mean many
things.
   Observed behavior:

Customer says that our networkRetries option found in file
/etc/sysconfig/rhn/up2date shows improper behavior if set to 0 or 5 

Customer included tcpdumps which are supposed to show this is true.

   Desired behavior:

4. Specific action requested of SEG:

Please verify that the options 0 and 5 are acting as suggested in code:

In /etc/sysconfig/rhn/up2date we set the following parameter:

'networkRetries'    : ("Number of attempts to make at network
connections before giving up",5)

During registration we try and connect to the serverUrl coming in from
'serverUrl' (/etc/sysconfig/rhn/up2date) and do the call to remote
server as:

def doCall(method, *args, **kwargs):
   log = up2dateLog.initLog()
   cfg = config.initUp2dateConfig()

--> 'cfg' will read the whole /etc/sysconfig/rhn/up2date file.

   ret = None

   attempt_count = 1
   attempts = cfg["networkRetries"] or 5

--> 'attempts' will read the config value set for networkRetries, if the
value is not set it will use '5' as default.

while 1:
       failure = 0


Interested in knowing what would be the business impact if this code
indeed is not working as advertised.


5. Is a defect (bug) in the product suspected? yes/no
   Bugzilla number (if one already exists):

possible bug, unable to find anything to match within bugzilla 




Issue escalated to Support Engineering Group by: rmunilla.
Internal Status set to 'Waiting on SEG'
Status set to: Waiting on Tech

This event sent from IssueTracker by vgaikwad  [Support Engineering Group]
 issue 342150

Event posted on 09-18-2009 11:01am EDT by rmunilla

# grep networkRetries /etc/sysconfig/rhn/up2date
networkRetries[comment]=Number of attempts to make at network connections
before giving up
networkRetries=0

[root@localhost ~]# rhnreg_ks --username=rhn-support-rmunilla
--password=**** --profilename=urltest-0 --force -vvv
A socket error occurred: (111, 'Connection refused'), attempt #1
A socket error occurred: (111, 'Connection refused'), attempt #2
A socket error occurred: (111, 'Connection refused'), attempt #3
A socket error occurred: (111, 'Connection refused'), attempt #4
A socket error occurred: (111, 'Connection refused'), attempt #5
An error has occurred:
Connection refused
Error communicating with server. The message was:
Connection refused
See /var/log/up2date for more information

[root@localhost ~]# cat /etc/redhat-release 
Red Hat Enterprise Linux Server release 5.3 (Tikanga)



This event sent from IssueTracker by vgaikwad  [Support Engineering Group]
 issue 342150

Event posted on 09-18-2009 11:28am EDT by vgaikwad

Hello Rob,

Thank you for taking this further, I'm now able to reproduce this issue.

So, this indeed looks like a bug. 

attempts = cfg["networkRetries"] or 5

if networkRetries is set to 0, it is assumed that the value is "False"
and it moves to the other part of the 'OR' which is '5'. That's the
reason why it makes 5 attempts.

Here's the patch that should fix this behaviour:

diff -up up2date_client/rpcServer.py.patch up2date_client/rpcServer.py
--- up2date_client/rpcServer.py.patch	2009-09-19 00:34:18.000000000 +0530
+++ up2date_client/rpcServer.py	2009-09-19 00:54:59.000000000 +0530
@@ -185,14 +185,15 @@ def getServer(refreshCallback=None):
 
 
 def doCall(method, *args, **kwargs):
     log = up2dateLog.initLog()
     cfg = config.initUp2dateConfig()
     ret = None
 
     attempt_count = 1
-    attempts = cfg["networkRetries"] or 5
+    if cfg["networkRetries"]:
+       attempts = cfg["networkRetries"] or 5
+    else:
+       attempts = 0
 
     while 1:
         failure = 0

I've verified this on a RHEL5.4 system and it works as expected now.
Please ask the customer to try the same and provide us the feedback.

regards,


This event sent from IssueTracker by vgaikwad  [Support Engineering Group]
 issue 342150

Event posted on 09-18-2009 12:30pm EDT by rmunilla

STATUS UPDATE:
1. Your issue has been successfully recreated
2. Engineering has confirmed and we have found the snippet of code which
may be causing this issue
3. A patch has been created by engineering and I am going to test the
patch.
4. Upon successful testing and results I will update the ticket again.

In the meantime, if you would like to test the patch please let us know. 
Thank you for your cooperation and patience.

Regards,
Robert


This event sent from IssueTracker by vgaikwad  [Support Engineering Group]
 issue 342150

Sending        up2date_client/rpcServer.py
Transmitting file data .
Committed revision 188934.

Revised networkRetries logic:

* treat all values less or equal to zero as: make exactly one connection
attempt
* treat all values greater than zero as: make exactly that many connection
attempts

According to this specifying one or zero will have the same effect
(i.e. exactly one connection attempt).

Sending        rhn-client-tools/src/up2date_client/rpcServer.py
Transmitting file data .
Committed revision 188970.

hello,
It works as described but when I set nonsense:
networkRetries=A
it runs unlimited, shouldn't be there some default - for.ex. 5 ?

(In reply to comment #15)
> hello,
> It works as described but when I set nonsense:
> networkRetries=A
> it runs unlimited, shouldn't be there some default - for.ex. 5 ?    

This might be worth fixing, in a different (new) bug though.

> (In reply to comment #16)

OK, filled:
 Bug 554693 -  networkRetries = nonsence runs unlimited, set some default

other test procedure:
1. iptables -I OUTPUT 1 -p tcp --dport 443 -o eth0 -j DROP

2. # grep networkRetries /etc/sysconfig/rhn/up2date 
networkRetries=<some number here>

3. rhnreg_ks -vvv --username=****** --password=***** --force
--server=https://xmlrpc.rhn.redhat.com/XMLRPC 
--
all works as expected

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 therefore 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-2010-0270.html