Bug 143820 - (IT#61897) rhn-applet-gui (rhn-applet-2.1.18-4) crashes on startup.
rhn-applet-gui (rhn-applet-2.1.18-4) crashes on startup.
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: rhn-applet (Show other bugs)
All Linux
medium Severity high
: ---
: ---
Assigned To: Robin Norwood
Beth Nackashi
: 143896 (view as bug list)
Depends On:
Blocks: 191074 191079
  Show dependency treegraph
Reported: 2004-12-28 19:40 EST by Ian Laurie
Modified: 2007-11-30 17:07 EST (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-05-08 15:09:52 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
cache and config files that cause this error on my box. (44.79 KB, application/x-zip)
2005-01-10 14:25 EST, Chris Evich
no flags Details

  None (edit)
Description Ian Laurie 2004-12-28 19:40:30 EST
Description of problem:
rhn-applet-gui crashes on startup.

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

How reproducible:

Steps to Reproduce:
1. Run rhn-applet-gui
Actual results:
Crashes.  When run from the command line:

server# rhn-applet-gui
Traceback (most recent call last):
  File "/usr/bin/../share/rhn/rhn_applet/rhn_applet.py", line 460, in
  File "/usr/bin/../share/rhn/rhn_applet/rhn_applet.py", line 577, in
    if self.nag_check():
  File "/usr/bin/../share/rhn/rhn_applet/rhn_applet.py", line 538, in
    bc = self.model.has_base_channel()
  File "/usr/bin/../share/rhn/rhn_applet/rhn_applet_model.py", line
335, in has_base_channel
    base_channel = source.has_base_channel()
  File "/usr/bin/../share/rhn/rhn_applet/rhn_applet_rpc.py", line 181,
in has_base_channel
    raise rhnAppletRPCFault(f.faultCode, f.faultString)
rhn_utils.rhnAppletRPCFault: Server Communication Error -140:
Error Message:
    Your system was not found in the RHN database
Error Class Code: 140
Error Class Info: Unable to look up server

Expected results:
Should run normally.

Additional info:
The error that the system isn't found in the RHN database is probably
bogus, as I can run up2date and it seems to connect fine.  Also
logging into RHN shows the system as active etc. and shown that the
last check-in was 2004-12-28 18:58:41 EST.  Accounting for time
differences, that's about 48 hours ago.
Comment 1 Ian Laurie 2004-12-29 16:18:38 EST
The text version seems to work [I think]:

server# rhn-applet-tui --verbose
rpm db mtimes: 0, 1104354752, 1104355009.81
Beginning RPM iter (match, (0,))
Finished RPM query (match, (0,))
Ended RPM query for installed packages
Beginning RPM iter (findbyprovides, ('redhat-release',))
Finished RPM query (findbyprovides, ('redhat-release',))
Beginning RPM iter (findbyfile, ('/boot/vmlinuz-2.4.21-27.0.1.EL',))
Finished RPM query (findbyfile, ('/boot/vmlinuz-2.4.21-27.0.1.EL',))
server says to use cached copy
No package updates are needed.

Comment 2 Andrew D. 2004-12-31 15:11:02 EST
*** Bug 143896 has been marked as a duplicate of this bug. ***
Comment 3 Max Spevack 2005-01-03 10:29:05 EST
I am trying to reproduce with no success.  My environment is as follows:

- rhel-as-3-u4 freshly installed
- system registered successfully to RHN
- as root, rhn-applet checks in, and I can use it to lauch up2date and
successfully update packages
- as non-root, rhn-applet checks in, and I can use it to launch
up2date and successfully update packages

version information: rhn-applet-2.1.18-4

Ian, can you give anymore information?  Setting to NEEDINFO.
Comment 4 Max Spevack 2005-01-03 10:37:30 EST
After letting up2date bring the system fully up to date, I restarted X
and the rhn-applet is still working correctly (as a non-root user).
Comment 5 Ian Laurie 2005-01-03 21:46:04 EST
Max, this doesn't look right, does it?

server# rpm -V rhn-applet
S.5....T c /etc/sysconfig/rhn/rhn-applet
SM5....T   /usr/share/rhn/rhn_applet/rhn_applet.pyc
SM5....T   /usr/share/rhn/rhn_applet/rhn_applet_animation.pyc
SM5....T   /usr/share/rhn/rhn_applet/rhn_applet_apt.pyc
SM5....T   /usr/share/rhn/rhn_applet/rhn_applet_dialogs.pyc
SM5....T   /usr/share/rhn/rhn_applet/rhn_applet_model.pyc
SM5....T   /usr/share/rhn/rhn_applet/rhn_applet_protocols.pyc
SM5....T   /usr/share/rhn/rhn_applet/rhn_applet_rpc.pyc
SM5....T   /usr/share/rhn/rhn_applet/rhn_applet_rpm.pyc
SM5....T   /usr/share/rhn/rhn_applet/rhn_applet_version.pyc
SM5....T   /usr/share/rhn/rhn_applet/rhn_applet_yum.pyc
SM5....T   /usr/share/rhn/rhn_applet/rhn_sources.pyc
SM5....T   /usr/share/rhn/rhn_applet/rhn_utils.pyc

I'm going to re-install it.
Comment 6 Ian Laurie 2005-01-03 22:13:53 EST
It seems the above may be normal.  Same output after I re-installed
and ran it for the first time.  My system is rhel-ws-3-u4.  Duplicate
bug 143896 has a good description of the problem, fits my case perfectly.

Max, what info can I send you from my system that would be helpful?
Comment 7 Ian Laurie 2005-01-03 22:35:11 EST
Max, The subtlety of your comment "as a non-root user" just sank in....

If I log in as a non-root user rhn-applet-gui works.  Before update 4
it worked for root and non-root.  Check if after the update you can
use it as root.  I can't.

Comment 8 Andrew D. 2005-01-04 13:26:10 EST
Mine crashes both as root and non-root user. I tried re-installing,
same result.
Comment 9 Andrew D. 2005-01-04 14:14:17 EST
Hi guys,
Sorry for all the comments. I got mine to work. Here's what I did.
1) delete .rhn-applet.conf and .rhn-applet.cache from the users directory.
2) run rhn-applet-gui and configure it. It will fail as before.
3) At this point I decided to run rhn-applet-tui. It worked, as before.
4) I decided to re-run rhn-applet-gui and it worked! It connects and
launched up2date with no problems (except for many libglade-WARNING
and GLib-GObject-WARNING when run from terminal).
These steps seem to work for both root and non-root users.
Comment 10 Ian Laurie 2005-01-04 15:44:29 EST
Andrew, your steps fixed my problem as well, thanks.  

The "gui" failed again for me as well, until "tui" was run at least
one time.
Comment 11 Andrew D. 2005-01-04 18:49:02 EST
You're welcome. I'm glad it worked for you as well. When you mentioned
that it worked for some users but not others I suspected that it must
be something local, not global. The only things I could find in the
user home directories that could be associated with the rhn-applet
were the conf and cache files above. It seems there's something in the
graphical end of rhn-applet which is keeping it from configuring and
connecting properly on some systems.
Kind regards, 
Comment 13 Andrew D. 2005-01-07 14:09:14 EST
Mine failed again this morning. Same error as before. I re-ran the
steps above and it now works. When I run rhn-applet-tui --verbose
after configuring the gui (step 3 above) I get the message below.
Afterwards it works fine.

rpm db mtimes: 0, 1105046641, 1105124457.55
Beginning RPM iter (match, (0,))
Finished RPM query (match, (0,))
Ended RPM query for installed packages
Beginning RPM iter (findbyprovides, ('redhat-release',))
Finished RPM query (findbyprovides, ('redhat-release',))
Beginning RPM iter (findbyfile, ('/boot/vmlinuz-2.4.21-27.0.1.EL',))
Finished RPM query (findbyfile, ('/boot/vmlinuz-2.4.21-27.0.1.EL',))
can't open for reading /home/adebened/.rhn-applet.cache: [Errno 2] No
such file or directory: '/home/adebened/.rhn-applet.cache', trying to
remove it...
packages received from server, mtime 20050105103841
No package updates are needed.
Comment 14 Chris Evich 2005-01-10 12:27:27 EST
I was having this problem as well so I debugged the .rhn-applet.conf
file a bit further.  It seems the default option for consent is
"consent=". However in my non-working version of the file it is
specified as "consent=1".  I am able to reproduce this error by
toggeling the two options between "" and "1".  This is why removing
the file works, it defaults the option to "" which works.  "1" leads
to the error.  That traceback is confusing though as it suggests some
other problem.
Comment 15 Chris Evich 2005-01-10 12:44:16 EST
Further testing demonstrated the behavior seems also tied to the
presence (or lack) of .rhn-applet.cache and/or it's contents.  I am
now getting inconsistant failures, though somehow changing the
"consent=" option affects this erronous behavior.
Comment 16 Adrian Likins 2005-01-10 13:46:52 EST
I've tried:

1) no .rhn-applet.cache, no .rhn-applet.conf
2) no .rhn-applet.cache, .rhn-applet.conf with "consent="
3) no .rhn-applet.cache, .rhn-applet.conf with "consent=1"
4) a .rhn-applet.cache, no .rhn-applet.conf
5) a .rhn-applet.cache, .rhn-applet.conf with "consent="
6) a .rhn-applet.cache, .rhn-applet.conf with "consent=1"

All cases started up correctly. So theres something 
else I'm missing. 

What kind of configs are the boxes seeing this using? Are they
pointed at https://xmlrpc.rhn.webdev.redhat.com/XMLRPC or
a sattelite? 

Are http proxies in play? 

is "up2date default" enabled in /etc/sysconfig/rhn/sources?

Comment 17 Chris Evich 2005-01-10 14:24:46 EST
That's the bizzaire thing, I had the same thing happen to me.  Perhaps
the "consent=" thing I found was a red herring.  When I had my
customer just delete those files, he got the same error two more times
but then it started working correctly the third time.  

However, it always seems to give this error with the original cache
and conf file.  Luckely I saved a copy of them and will attach to this

[Gnome rhn-applet 2.1.17] Box is pointed at
https://xmlrpc.rhn.redhat.com/XMLRPC, not using any proxies, up2date
default is specified in sources.
Comment 18 Chris Evich 2005-01-10 14:25:44 EST
Created attachment 109572 [details]
cache and config files that cause this error on my box.
Comment 19 Andrew D. 2005-01-10 14:28:24 EST
Hi, Here's the relevant info for my system.

Consent=1 seems to be set all the time in ~/.rhn-applet.conf (even
after re-running after deleting the .conf file).

Server URL in: /etc/sysconfig/rhn/rhn-applet file:

No http proxies are set.
Comment 21 Robert Locke 2005-01-10 20:29:50 EST
I think I might have fonud at least my problem.  I was getting the
same symptoms.  Checking /etc/sysconfig/rhn, I found two files
rhn-applet, one with an .rpmnew extension.  The difference for me
seems to simply be the shift from one CNAME to another in server_url
but perhaps more importantly, the one that did not work had a uuid=<an
actual value> but the .rpmnew had "uuid=UNSPECIFIED".   If I use the
.rpmnew file, rhn-applet-gui seems to connect now.  We'll see if it
continues to connect tomorrow... :-)  HTH
Comment 22 Chris Evich 2005-01-11 10:02:40 EST
I also found this .rpmnew file.  However I am still able to reproduce
this problem even after renaming it.  The key on my system is to drop
in the .rhn-applet* files (which are attached here).  

If, after removing .rhn-applet* files, subsequently running the gui
shows that it's working.  Though the hover message is "Click for
critical updates...".  Because "consent=", clicking on the icon makes
me go through the "setup" wizard.  Subsequently, it dies with the same
error as above just after clicking "finish". If I right-click on it,
choose exit, then run it again (w/o touching the newly created
.rhn-applet* files) it works fine.  I was able to reproduce this 3
times without fail.
Comment 23 Ian Laurie 2005-01-14 03:43:42 EST
rhn-applet-gui is now failing for me regularly.  The fixes in comment
#9 still work to get it going, but the fix is only temporary.
Comment 24 Chris Evich 2005-01-14 09:27:45 EST
Did quite a bit of digging and have a good indication of where the
problem is.  When the new "nag" code is triggered but the system is
registered, has_base_channel() is called but throws a rpclib.Fault

Further analysis needs to be done on the root cause, however  one
workaround is to disable the nag check.  You can do this by setting
"remindTimeStamp=NEVERREMIND" in .rhn-applet.conf
Comment 25 Chris Evich 2005-01-17 08:55:51 EST
I've been asked "what are the consequences of setting remindTimeStamp
to NEVERREMIND? Will users not be notified of updates?"

To the best of my knowledge this setting doesn't have anything to do
with being notified.  It's a timestamp wherin every 3 days the applet
checks to make sure the system is registered with RHN.  This results
in a call to has_base_channel() which is failing with an xml-rpc error.

The consequences of this setting should be minimal, the _real_ problem
lies within the base-channel checking xml-rpc code.  This setting
mearly  prevents the non-functional code from running via this
Comment 26 Adrian Likins 2005-01-17 11:49:25 EST
Indeed, NEVERREMIND only stops the "remind" message, not
any other rhn_applet functionality. 

Looking at the code, the has_base_channel throwing an
rpc fault is the only thing that makes sense in that case. 
The question is why is it throwing an exception. My suspicion
is the wrong uuid getting sent up, and the various work
arounds fix that. Why they seem to be only temporary
I currently have no idea. 
Comment 27 Adrian Likins 2005-01-17 12:03:21 EST
What is the contents of /etc/sysconfig/rhn/up2date-uuid on boxes
showing this?
Comment 28 Adrian Likins 2005-01-17 13:48:07 EST
Also, just to verify, the subject of the bug is that "rhn-applet
crashes on startup" so I assume that is when people are
seeing the crash? (sans comment #22 which indicates other cases)
Comment 29 Andrew D. 2005-01-17 14:32:29 EST
That's correct for me. I've only noticed the crash when I (or the
system at login) starts rhn-applet-gui. I haven't noticed failures
once it's up and running.
Comment 30 Adrian Likins 2005-01-17 14:35:14 EST
Are the systems showing this all old registrations, or mix
of new, or all new. 

It looks like the systems are registered, but without
the up2date-uuid being associated with the systemid. 

Unless there is a bug in the registration I dont
know of, the only way to do this is to have registered
with older versions of up2date/rhn_register. 
Comment 31 Adrian Likins 2005-01-17 14:38:18 EST
I've got a patch to fix the crash, but I'm still tracking
down _why_ this is happening. 
Comment 32 Chris Evich 2005-01-17 14:47:04 EST
Isn't this failure likely the case if one installs from CD, then
incrementally updated as packages were released on RHN?

It sounds to me like deleting the system's RHN profile and
re-registering the system should resolve the problem.

However, if many people/systems are experiencing this then, that would
be a less than desirable solution.  Is there a way to get those uuid's
associated with systemid's via some other means?  Perhaps a simple
python script could fix this from the client machine side?

Comment 33 Andrew D. 2005-01-17 14:50:14 EST
I registered my current RHEL 3 system back in May or so. The uuid in
/etc/sysconfig/rhn/up2date-uuid is different on my system than the
uuid in /etc/sysconfig/rhn/rhn-applet . 
Comment 34 Adrian Likins 2005-01-17 17:33:09 EST
re #32, off hand, I can't see why upgrading the packages
at a different time would matter. The concern was whether
or not old installs were somehow not getting the *uuid's
associated with the proper systemid. All the current
code seems to be okay.

Comment 37 Ronald Cole 2005-03-31 17:48:10 EST
I also deleted my system's RHN profile, deleted, and re-registered with RHN.  I
see the same symptoms as in comment #33: different uuid's.

If I log on and run up2date and stay logged on, the rhn-applet-gui will not
indicate when updates are available!
Comment 45 Fanny Augustin 2006-04-13 15:50:34 EDT
Moving bugs to the CanFix List
Comment 46 Robin Norwood 2006-05-08 15:09:52 EDT
Since this seems to be no longer an issue, closing.
Comment 47 Fanny Augustin 2006-05-08 15:31:33 EDT
This bug did not make the code freeze and it will not be fiixed during this
release cycle.  Re-aligning bug to the next release

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