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
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
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
if this look kosher, then real debugging might be needed, for
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
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:
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
$ 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 !
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 :-)
Fedora Core 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
found 48 packages for local-updates-testing
last_modified : Mon, 26 Jan 2004 19:16:59 GMT
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
again, thanks a lot !
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.
/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, 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.
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).