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
*** Bug 689771 has been marked as a duplicate of this bug. ***
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.
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