Description of problem: The rhn-applet does not appear to be checking for updates on Fedora Core 1. This is rhn-applet-2.1.4-3 with all except "todays" updates installed. If I manually cause it to "Check for updates", the updates are found. It may be that the period is just too long but I see now ability to set the "recheck for updates" time interval.
I've just (finally) seen something similar with 2.1.5. As a full disclosure this was on a WBEL machine, but using the FC1 rhn-applet. Since I'm using a local mirror I can say for sure that the applet IS checking for updates (gets a 200 response and downloads the header.info file), but the applet doesn't change. I've left the machine in this state so that we can test, what is needed?
Very interesting, I was afraid that the problem came from the If-Modified-Since HTTP support and that for some reason the applet was never seeing the upgrade. Without stopping the applet can you check the cache in ~/.rhn-applet/your_source_name.yum the first lines should be - a description - the URL for the source - one line containing the Last-Modified timestamp as returned by the server then the rest of the file is the header.info. Can you check: - the timestamp correspond to what the server now delivers for that resource (can be checked by hand from the shell by asking directly via "telnet server 80" and compose and HTTP/1.0 request, then read teh answer if you're used to this) - the content of that file cache is actually what the server now delivers. if this look kosher, then real debugging might be needed, for example: 1/ without stopping the applet, run strace -p applet_pid > /tmp/log to get a log of the filesystem calls done by the applet the check what's happening every 4 hours :-\ 2/ by restarting the applet: - edit /usr/share/rhn/rhn_applet/rhn_utils.py around line 108 to switch DEBUG_LEVEL to 2 - also modify the refresh frequency to not wait for 4 hours around line 108 but in rhn_applet_yum.py next_checkin = time.time() + 60; would recheck every minute - relaunch the applet from the command line and log the errors Daniel
Some preliminary info, more to follow. The cache file has a good date and header info (diff reports the only difference is the lines you point out above). Unfortunately, past history has shown that if I restart the applet that it will "see" the updates on it's first check-in, so I will have to wait until later this afternoon and post the strace info.
OK, here's the strace. Just in case I also put it at: http://whooper.org/download/bugzilla/rhnapp.log Sorry about the size (~8.2Mb), I had to start it sooner than I'd hoped. Also a note that the server has been giving the applet 304's since the one 200 response last night. I guess this would be expected since the cache was updated.
Created attachment 97176 [details] Strace of rhn-applet proccess Duh, compression helps. Sorry, it's been one of those days.
Created attachment 97200 [details] Strace of rhn-applet process (bzip2) Fixed the Content Type
Another data point, but unfortunately I didn't have strace going. I ran up2date (just to make sure I wasn't crazy and I did have an update): $ sudo /usr/sbin/up2date-nox --dry-run -u Immediately after the up2date run, the rhn-applet changed to the "!".
Hum .... that last data point might indicate that the image of the installed rpm data set that the applet caches in memory might be the problem. The applet checks if the rpm database has changed and then updates the cache. /usr/sbin/up2date-nox --dry-run -u might trigger this. On the other hand I'm quite surprized that this in-memory cache might have a problem, that code has been running for a very long time, and should be really stable. I will try to look at your logs ASAP, thanks a lot for the data you provided ! Daniel
Maybe that is on to something... Another data point: FC1 machine. I'm not sure what triggered this one to flip to the "!", but it was either the fact that I used "less /etc/sysconfig/rhn/sources" or used yum to check for and install some updates. This one is a remote machine that I was using SSH into, so I'm not 100% sure what triggered it, but I know for a fact that yesterday it was a check and after the above mentioned things it is now a "!".
To help make up for that horrible strace last week :-) Different machine: Fedora Core 1 rhn-applet-2.1.7-1 The update needed is the foomatic released to testing today. I've included 2 straces: fedorarhnapp which is the first check (verified by the apache logs on the server) that got a 200 response and should have shown an update and fedorarhnman which is a manual check (right click, "Check for updates") which gets the expected 304 response but does trigger the applet to change to a "!". I'll make the debugging changes you mention above so that I'm ready for next time.
Created attachment 97263 [details] Smaller strace of automatic check
Created attachment 97264 [details] Strace of manual check that does cause applet to alert
Created attachment 97322 [details] Console Debug Info Finally some debug info from the console. Same FC1 machine as list time, with the xmms update released to -testing. The first couple of checks were before I updated the yum repo, let it get a 200 for a check, then waited for another check. The next run was after stopping the applet (and copying the first run's output) then restarting it, which results in a "!".
Thanks for all the logs, sorry I got diverted a bit. What I see from the console informations is that between both runs: found 48 packages for local-updates-testing last_modified : Mon, 26 Jan 2004 19:16:59 GMT turned into found 51 packages for local-updates-testing last_modified : Thu, 29 Jan 2004 02:37:44 GMT Those 2 messages get printed when the on-disk cache is loaded. This means somewhat in the first session, the check to the server returned a 200 instead of a 304, the applet updated its cache but didn't recompute the applet state. Well that's the only way I can make sense of this log. This is surprizing, thanks a lot for the informations, that's another scenario I need to try to reproduce to really see what's happening, again, thanks a lot ! Daniel
This bug bites me too. This is a Fedora Core 1 box that was upgraded from Red Hat Linux 7.2. I can confirm that using Yum to install one of several available updates (yum update package-name) causes the applet to turn red almost immediately. I also used RPM to install a manually downloaded package (rpm -F package.rpm), and after ten seconds or so the applet turned red. Reading /etc/sysconfig/rhn/sources doesn't seem to affect the applet, but editing the file (only removing a few empty lines at the end) made the applet turn red within a minute. Shortly thereafter I discovered that my ISP had been blocking my Internet connection for 18 hours, so obviously the applet didn't immediately check for updates when it found that the config file had changed, but changed its state based on data it had retrieved earlier.
Just as a point of note, our two FC1 desktops here have the exact same problem - each morning I have to actually click on "Check for Updates" to see the updates. That, or run up2date/yum on my own. I'm almost cosidering putting an "up2date -l >/dev/null 2>&1" in cron for about 7 AM so the applet will show the proper state when I get in. :)
Any luck with reproducing this problem, Daniel? As for Comment #16, rhn-applet-tui should do the trick.
Since FC2 Test3 has rhn-applet-2.1.7-1.1, this problem carries through to it, also.
I'm also seeing this exact same problem on FC2, rhn-applet-2.1.7-1.1. Installing one of many updates available with another tool such as yum, rug, or red-carpet causes the icon to instantly change from a blue tick to a red exclamation mark.
I too have experienced this problem. FC1 /etc/sysconfig/rhn/sources pointing to my local rsync'd mirror: "yum fc1-updates file:/home/mirror/fc1-updates" My cron runs every day to update my mirror, and the rhn_applet doesn't show an "!" when changes updates are available. Is anybody listening? (this been a bug since 12/2003?)
I am not the maintainer of rhn_applet anymore. Seems to me that a file URL starts with "http:///" see RFC 1630. Daniel
Daniel, this problem is *not* exclusive to file: URL's. Who is the proper maintainer for rhn_applet? Let's get the bug pointed at the correct person, hm?
Fedora Core 1 is maintained by the Fedora Legacy project for security updates only. If this problem is a security issue, please reopen and reassign to the Fedora Legacy product. If it is not a security issue and hasn't been resolved in the current FC5 updates or in the FC6 test release, reopen and change the version to match. Thanks! NOTE: Fedora Core 1 is reaching the final end of support even by the Legacy project. After Fedora Core 6 Test 2 is released (currently scheduled for July 26th), there will be no more security updates for FC1. Please use these next two weeks to upgrade any remaining FC1 systems to a current release.
Closed per above message and lack of response. Note that FC1 and FC2 are not even supported by Fedora Legacy anymore. Also note that rhn-applet is deprecated and not included in the non-Legacy FC versions (5 and 6).