Bug 143820 (IT#61897)
Summary: | rhn-applet-gui (rhn-applet-2.1.18-4) crashes on startup. | ||||||
---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 3 | Reporter: | Ian Laurie <nixuser> | ||||
Component: | rhn-applet | Assignee: | Robin Norwood <robin.norwood> | ||||
Status: | CLOSED CANTFIX | QA Contact: | Beth Nackashi <bnackash> | ||||
Severity: | high | Docs Contact: | |||||
Priority: | medium | ||||||
Version: | 3.0 | CC: | adebened, bjohnson, bretm, cevich, craig.lawson, eric.eisenhart, mollo, tao, tscargo, vgaikwad | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | All | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2006-05-08 19:09:52 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Bug Depends On: | |||||||
Bug Blocks: | 191074, 191079 | ||||||
Attachments: |
|
Description
Ian Laurie
2004-12-29 00:40:30 UTC
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 Ignoring No package updates are needed. server# *** Bug 143896 has been marked as a duplicate of this bug. *** 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. 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). 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 server# I'm going to re-install it. 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? 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. Mine crashes both as root and non-root user. I tried re-installing, same result. 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. 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. 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, Andrew 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 Ignoring No package updates are needed. 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. 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. 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? 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 issue. [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. Created attachment 109572 [details]
cache and config files that cause this error on my box.
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: server_url=https://www.rhns.redhat.com/APPLET No http proxies are set. 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 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. 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. 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 exception. 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 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 mechanism. 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. What is the contents of /etc/sysconfig/rhn/up2date-uuid on boxes showing this? 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) 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. 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. I've got a patch to fix the crash, but I'm still tracking down _why_ this is happening. 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? 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 . 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. 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! Moving bugs to the CanFix List Since this seems to be no longer an issue, closing. 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 |