Bug 77416 - rhn-applet-gui occationally greys out
rhn-applet-gui occationally greys out
Status: CLOSED ERRATA
Product: Red Hat Linux
Classification: Retired
Component: rhn-applet (Show other bugs)
8.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Veillard
Red Hat Satellite QA List
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-11-06 14:00 EST by Gene Czarcinski
Modified: 2007-04-18 12:48 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-04-09 12:35:18 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 Gene Czarcinski 2002-11-06 14:00:42 EST
Description of Problem:
The rhn-applet gui panel applet run fine most of the time.  However,
occationally it will go to a grey "button" with a question mark. When this
happens, the "Check for updates" is greyed out so I cannot force a check of the
server and update the status.  The only way I have found to "fix" this is to
exit the applet and then restart it.  When restarted, itimmediately starts with
the white check mark and blue "button".

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


How Reproducible:
Happens but cannot just cause it.

Steps to Reproduce:
1. 
2. 
3. 

Actual Results:


Expected Results:


Additional Information:
Comment 1 Adrian Likins 2002-12-02 17:41:59 EST
component changed to rhn-applet
Comment 2 Daniel Veillard 2003-04-08 05:39:51 EDT
The current version in Red hat 9 will retry on networking errors
and indicate with a new flag is the applet could not connect to
the RHN server. As soon as the connection is put back in place it
will resume the monitoring. I think the problem about the menu
options being unavailable in that case has also been fixed,

  thanks for the report,

Daniel
Comment 3 Gene Czarcinski 2003-04-08 07:47:12 EDT
Sorry to reopen this but it happened again (9 with all errata).  The panel
applet did show the new icon indicating that it could not contact the server. 
However, after waiting about a half a day with it not coming back, I brought up
another system and verified that the server could be contact (its applet worked
fine) while the original system still showed the non-connection.  After exiting
and restarting the applet, it worked fine.

When in this "new icon mode", it would be nice to "force" check-for-updates (it
i currently grayed out).
Comment 4 Daniel Veillard 2003-04-08 08:14:12 EDT
Have you tried to diagnose *why* the server could not be contacted ?
I have tried many different tests, including disconnecting the
network adapter, removing the default route, removing the adapter
and replugging it, disconnecting from one network and replugging
in another one with different IP confgurations.
In all cases the disconnection state was correctly flagged and
once back the normal status came back. I never managed to get the
problem though I'm working from France and crossing the transatlantic
line could be considered another risk factor.
I *need* a reproductible case to debug the problem you're seeing,
you are not providing one, and this works for every cases I tested.
You need to find what is so special with your configuration, and
report a way to reproduce it for me to debug and fix the problem.
Do you use a proxy ? Is the DNS stable ? Do you have any special 
networking setup ? Did the applet logged anything ? Have you tried
running it from the shell to get some extra informations ? Try to edit
/usr/share/rhn/rhn_applet/rhn_utils.py and increase DEBUG_LEVEL to 2
if you really can't get any hint.

You need to be proactive about the problem, again
if I can't reproduce it, there is no way I can debug it. So far
your report is "it doesn't work, the problem happens randomly",
it is not sufficient to fix it.

Daniel
Comment 5 Gene Czarcinski 2003-04-08 09:38:35 EDT
OK, First of all, this is not such a big deal that if you want to close it
again, I will let it sit.

My Internet connection is via a cable modem.  A firewall sits on the modem and
has a local dns server (which bounces unresolved references up to the ISP's dns
servers).  There is no proxy involved.

The local network is rock solid but the cable modem will occationally go out. 
The (cable modem) connnection uses dhcp to connect to the ISP.  Occationally,
the cable modem connection will go down for lang periods due to BIFF (backhoe
induced fiber failure) or equivalent.  This has not occurred recently.  However,
I have been getting these "cycles" where the cable interface will go down and
then come back up within about 10 to 20 seconds.  This is quick enough so that a
web browser just looks "slow".

I am not sure what happens when the rhn-applet get a problem since these have
mostly happened over night.

When it does get into the "network error" situation, it seems to be locked into
the mode and I cannot "force" check for updates.  However, when this occurs, I
can ge it going again by exiting and restarting the rhn applet.
Comment 6 Daniel Veillard 2003-04-08 10:30:16 EDT
Can you try to get traces/logs of what's going on ? The state diagram
of the program has been modified to have an extra condition which is
entered when a network error is detected. Maybe the frequency of the
network errors on your cable modem is able to trigger a case where this
error is not caught, and having the trace with a version 2.0.9 of the
rhn-applet package would allow to trace back to the missed exception and
fix the problem. Except that I honnestly have no idea ...

Daniel
Comment 7 Chip Turner 2003-04-09 12:35:18 EDT
An errata 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-2003-080.html

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