Bug 1271287 - yum hourly cron errors even when configured not to update
yum hourly cron errors even when configured not to update
Status: NEW
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: yum (Show other bugs)
7.1
Unspecified Unspecified
unspecified Severity medium
: rc
: ---
Assigned To: Michal Domonkos
BaseOS QE Security Team
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-10-13 10:26 EDT by rstory
Modified: 2017-07-18 06:27 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
patch for bug (1.06 KB, patch)
2015-10-13 10:26 EDT, rstory
no flags Details | Diff

  None (edit)
Description rstory 2015-10-13 10:26:20 EDT
Created attachment 1082467 [details]
patch for bug

Description of problem:
I have yum-cron installed to do daily updates. Hourly conf is set not to download, update or output messages. However, sometimes when a different mirror gets selected, I start getting this message, every hour:

  Not using downloaded repomd.xml because it is older than what we have

It also contains timestamp info. I get this message every hour until I run 'yum clean all' on the machine.

Version-Release number of selected component (if applicable):
yum-cron-3.4.3-125.el7.centos.noarch

How reproducible:
Frequently

Steps to Reproduce:
1. run yum update
2. set hourly conf to 'no' for donwload, apply and message options
3. switch to mirror with older repo metadata

Actual results:
error/warning message every hour

Expected results:
Yum shouldn't even run to update metadate when it is not configured to download, update or output messages.

Additional info:
I've attached a patch that moved the update/download/message option check earlier in checkUpdates, and this issue goes away...
Comment 1 Habig, Alec 2015-10-13 12:10:34 EDT
Good catch!  To get this fix implemented now, though, the bug should be reported against yum itself: as yum-cron is now something that's built out of the main yum srpms rather than something I can fix.

so I've reassigned it to Jeff (he's getting the regular yum EPEL bugs).  If this isn't correct, please let me know so we can get this patch to the right person.
Comment 2 Anssi Johansson 2015-10-13 12:16:52 EDT
Last time I looked, yum-cron was a RHEL package, built from yum.srpm. Thus this bug should be filed for Red Hat > Red Hat Enterprise Linux 7, component yum.
Comment 3 rstory 2015-10-13 12:35:30 EDT
I changed the Product to RHEL 7, component yum.
Comment 5 Michal Domonkos 2016-02-02 08:51:16 EST
Hi,

Thank you for the patch.  However, we decided not to apply it as it would break one particular scenario in which yum-cron is used to only fetch metadata.  In such a scenario, both the download_updates and apply_updates options would be set to "no", and it's likely that update_messages would also be "no", which would cause yum-cron to not even fetch metadata when run.  That is also the default configuration shipped with yum-cron (see /etc/yum/yum-cron-hourly.conf).

We will take a look at how this (if at all) can be properly fixed.  For now, I'd suggest that you just disable the hourly yum-cron job if you don't need the metadata updates.  With the patch, yum-cron would exit immediately (without doing anything) when used in that configuration anyway.

Thanks!
Comment 6 Michal Domonkos 2016-02-22 10:09:04 EST
Oops, removing the accidental devack+

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