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:
component changed to rhn-applet
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
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).
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
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.
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
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