Bug 111302 - does not periodically check for updates
does not periodically check for updates
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: rhn-applet (Show other bugs)
1
All Linux
medium Severity medium
: ---
: ---
Assigned To: Robin Norwood
Beth Nackashi
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-12-01 15:58 EST by Gene Czarcinski
Modified: 2008-08-02 19:40 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-10-25 16:21:18 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Strace of rhn-applet proccess (215.29 KB, text/plain)
2004-01-22 13:43 EST, William Hooper
no flags Details
Strace of rhn-applet process (bzip2) (215.29 KB, application/octet-stream)
2004-01-22 19:13 EST, William Hooper
no flags Details
Smaller strace of automatic check (10.36 KB, application/x-bzip2)
2004-01-26 21:51 EST, William Hooper
no flags Details
Strace of manual check that does cause applet to alert (82.83 KB, application/x-bzip2)
2004-01-26 21:52 EST, William Hooper
no flags Details
Console Debug Info (5.31 KB, text/plain)
2004-01-28 22:11 EST, William Hooper
no flags Details

  None (edit)
Description Gene Czarcinski 2003-12-01 15:58:45 EST
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.
Comment 1 William Hooper 2004-01-21 20:59:08 EST
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?
Comment 2 Daniel Veillard 2004-01-22 02:38:49 EST
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
Comment 3 William Hooper 2004-01-22 11:28:19 EST
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.
Comment 4 William Hooper 2004-01-22 13:27:13 EST
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.
Comment 5 William Hooper 2004-01-22 13:43:40 EST
Created attachment 97176 [details]
Strace of rhn-applet proccess

Duh, compression helps.  Sorry, it's been one of those days.
Comment 6 William Hooper 2004-01-22 19:13:03 EST
Created attachment 97200 [details]
Strace of rhn-applet process (bzip2)

Fixed the Content Type
Comment 7 William Hooper 2004-01-22 22:04:55 EST
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 "!".
Comment 8 Daniel Veillard 2004-01-23 05:13:25 EST
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
Comment 9 William Hooper 2004-01-25 13:00:01 EST
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 "!".
Comment 10 William Hooper 2004-01-26 21:50:56 EST
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.
Comment 11 William Hooper 2004-01-26 21:51:50 EST
Created attachment 97263 [details]
Smaller strace of automatic check
Comment 12 William Hooper 2004-01-26 21:52:27 EST
Created attachment 97264 [details]
Strace of manual check that does cause applet to alert
Comment 13 William Hooper 2004-01-28 22:11:33 EST
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 "!".
Comment 14 Daniel Veillard 2004-01-29 04:58:43 EST
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
Comment 15 Björn Persson 2004-02-12 20:50:40 EST
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.
Comment 16 Ken Snider 2004-02-25 10:31:21 EST
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. :)
Comment 17 William Hooper 2004-03-18 19:40:39 EST
Any luck with reproducing this problem, Daniel?

As for Comment #16, rhn-applet-tui should do the trick.
Comment 18 William Hooper 2004-05-06 22:13:53 EDT
Since FC2 Test3 has rhn-applet-2.1.7-1.1, this problem carries through
to it, also.
Comment 19 Darren Brierton 2004-07-21 11:26:24 EDT
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.
Comment 20 Randy 2004-07-27 09:04:50 EDT
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?)
Comment 21 Daniel Veillard 2004-07-27 10:16:25 EDT
I am not the maintainer of rhn_applet anymore.
Seems to me that a file URL starts with "http:///" see RFC 1630.

Daniel
Comment 22 Ken Snider 2004-07-27 11:11:19 EDT
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?
Comment 23 Matthew Miller 2006-07-11 13:41:32 EDT
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.

Comment 24 John Thacker 2006-10-25 16:21:18 EDT
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).

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