Bug 667135 - [RHEL 5] rhn_check incorrectly reports success when packages weren't found due to out-of-date yum cache
Summary: [RHEL 5] rhn_check incorrectly reports success when packages weren't found du...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: yum-rhn-plugin
Version: 5.5
Hardware: All
OS: Linux
low
medium
Target Milestone: rc
: ---
Assignee: Milan Zázrivec
QA Contact: Martin Minar
URL:
Whiteboard:
: 689771 (view as bug list)
Depends On: 666545
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-01-04 15:12 UTC by John Ruemker
Modified: 2018-11-15 09:41 UTC (History)
9 users (show)

Fixed In Version: yum-rhn-plugin-0.5.4-19.el5
Doc Type: Bug Fix
Doc Text:
When using RHN Classic or RHN Satellite to schedule installation or update on the client system with outdated Yum's metadata cache, the "rhn_check" utility incorrectly reported success. This error has been fixed and the scheduled action fails if Yum does not find any new packages to install or update.
Clone Of: 666545
Environment:
Last Closed: 2011-07-21 07:14:23 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 671360 1 None None None 2021-01-20 06:05:38 UTC
Red Hat Product Errata RHBA-2011:0998 0 normal SHIPPED_LIVE yum-rhn-plugin bug fix update 2011-07-20 15:44:51 UTC

Internal Links: 671360

Description John Ruemker 2011-01-04 15:12:42 UTC
Cloning issue for RHEL 5. 

+++ This bug was initially created as a clone of Bug #666545 +++

Created attachment 471285 [details]
output of rhn_check -vvv and rpm -q to demonstrate the issue

Description of problem: Using Satellite, if you add packages to a channel, wait for the repodata to be generated, then schedule an install of those packages on a client system, if the cached metadata on that client has not yet expired (causing yum to not find the new packages) then rhn_check, and thus satellite, will still report that the scheduled action was successful even though the packages were not installed.

I have filed RHEL 6 and 5 bugs to request that rhnplugin-based channels be allowed to use metadata_expire to shorten the window that this is a problem on clients:

  https://bugzilla.redhat.com/show_bug.cgi?id=666463
  https://bugzilla.redhat.com/show_bug.cgi?id=666534

This partially solves the problem, however this does not address the root issue that satellite incorrectly reports that the packages were installed.  This bug is to request a change in this functionality.  

I filed the bug against rhn-client-tools because rhn_check seems to be the component that is incorrectly reporting success. However, this may also warrant a change in satellite itself.  Ideally when this occurs, satellite would schedule the action again or continue to retry it.  

Version-Release number of selected component (if applicable): rhn-check-1.0.0-39.el6.noarch (problem also exists in RHEL 5). 

How reproducible: Any time the yum cache was last generated within 6 hours and updated repodata is made available.

Steps to Reproduce:
1. Create a channel in Satelite
2. Register system to satellite
3. 'yum makecache' on system or install a package through Satellite interface
4. Add new packages to channel
5. Wait for repodata to regenerate, and then schedule package install/update from Satellite interface
6. 'rhn_check -vvv' from system (or wait for osad to run it)
  
Actual results: Operation reports as successful in both rhn_check and satellite interface, but packages are not actually installed.  

Expected results: Packages are installed, or satellite interface reports failure.  Ideally, the action would be rescheduled or retried.

Additional info: Screenshot of satellite displaying success is attached.  Full rhn_check -vvv output is attached.  Some interesting snippets:

   # rhn_check -vvv
   [...]
   D: check_action {'action': "<?xml version='1.0'?>\n<methodCall>\n<methodName>packages.update</methodName>\n<params>\n<param>\n<value><array><data>\n<value><array><data>\n<value><string>git</string></value>\n<value><string>1.7.1</string></value>\n<value><string>2.el6_0.1</string></value>\n<value><string></string></value>\n<value><string>x86_64</string></value>\n</data></array></value>\n<value><array><data>\n<value><string>initscripts</string></value>\n<value><string>9.03.17</string></value>\n<value><string>1.el6_0.1</string></value>\n<value><string></string></value>\n<value><string>x86_64</string></value>\n</data></array></value>\n</data></array></value>\n</param>\n</params>\n</methodCall>\n", 'version': 2, 'id': 324}
   [...]
   D: handle_action {'action': "<?xml version='1.0'?>\n<methodCall>\n<methodName>packages.update</methodName>\n<params>\n<param>\n<value><array><data>\n<value><array><data>\n<value><string>git</string></value>\n<value><string>1.7.1</string></value>\n<value><string>2.el6_0.1</string></value>\n<value><string></string></value>\n<value><string>x86_64</string></value>\n</data></array></value>\n<value><array><data>\n<value><string>initscripts</string></value>\n<value><string>9.03.17</string></value>\n<value><string>1.el6_0.1</string></value>\n<value><string></string></value>\n<value><string>x86_64</string></value>\n</data></array></value>\n</data></array></value>\n</param>\n</params>\n</methodCall>\n", 'version': 2, 'id': 324}
   D: handle_action actionid = 324, version = 2
   D: do_call packages.update ([['git', '1.7.1', '2.el6_0.1', '', 'x86_64'], ['initscripts', '9.03.17', '1.el6_0.1', '', 'x86_64']],) {'cache_only': None}
   [...]
   D: Called update [['git', '1.7.1', '2.el6_0.1', '', 'x86_64'], ['initscripts', '9.03.17', '1.el6_0.1', '', 'x86_64']]
   [...]
   D: Sending back response (0, 'Update Succeeded', {})
   D: do_call packages.checkNeedUpdate ('rhnsd=1',) {}
   D: local action status:  (0, 'rpm database not modified since last update (or package list recently updated)', {})
   D: rpcServer: Calling XMLRPC registration.welcome_message
   D: closed   db index       /var/lib/rpm/Providename
   D: closed   db index       /var/lib/rpm/Name
   D: closed   db index       /var/lib/rpm/Packages
   D: closed   db environment /var/lib/rpm
   # rpm -q git initscripts
   git-1.7.1-2.el6.x86_64
   initscripts-9.03.17-1.el6.x86_64

--- Additional comment from jruemker on 2010-12-31 10:36:55 EST ---

Created attachment 471286 [details]
screenshot of satellite event page showing success

--- Additional comment from jruemker on 2010-12-31 10:40:44 EST ---

Additional output to show that yum metadata caching is the cause of the packages not being installed:

[root@jrummy6-64 ~]# yum check-update
Loaded plugins: fs-snapshot, refresh-packagekit, rhnplugin
[root@jrummy6-64 ~]# yum clean all
Loaded plugins: fs-snapshot, refresh-packagekit, rhnplugin
Cleaning up Everything
[root@jrummy6-64 ~]# yum check-update
Loaded plugins: fs-snapshot, refresh-packagekit, rhnplugin
rhel-6-test                                                                                    |  871 B     00:00     
rhel-6-test/primary                                                                            | 4.6 kB     00:00     
rhel-6-test                                                                                                       8/8

git.x86_64                                            1.7.1-2.el6_0.1                                      rhel-6-test
initscripts.x86_64                                    9.03.17-1.el6_0.1                                    rhel-6-test

Comment 3 Milan Zázrivec 2011-03-22 12:33:59 UTC
*** Bug 689771 has been marked as a duplicate of this bug. ***

Comment 5 Eliska Slobodova 2011-06-15 12:35:21 UTC
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
When using RHN Classic or RHN Satellite to schedule installation or update on the client system with outdated Yum's metadata cache, the "rhn_check" utility incorrectly reported success. This error has been fixed and the scheduled action fails if Yum does not find any new packages to install or update.

Comment 6 errata-xmlrpc 2011-07-21 07:14:23 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2011-0998.html


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