Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
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...
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.
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.
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!
I am having a similar problem. All my servers (30+) produce various errors via email due to yum-cron-hourly.
Most of them look like:
Could not get metalink https://mirrors.fedoraproject.org/metalink?repo=epel-7&arch=x86_64 error was
14: HTTPS Error 503 - Service Unavailable
At first, I tried to modify the config file (/etc/yum/yum-cron-hourly.conf) but these errors are irrelevant to any of the config options, they are produced no matter what.
Eventually I had to disable yum-cron-hourly via my Ansible playbook, that was the only way that I could find to stop the errors.
Thank you.
A couple possible temporary workarounds to end the flood of 503 emails.
1. `# mv 0yum-hourly.cron /opt/0yum-hourly.cron.backup`
2. Filter them out in your mail client. If the emails go to a list of people, that's not ideal.
It's worth noting even setting the verbosity to -4 won't stop the 503 emails.
(In reply to Ray Foss from comment #11)
> It's worth noting even setting the verbosity to -4 won't stop the 503 emails.
This has been addressed upstream and a BZ has been created to backport this into RHEL:
https://bugzilla.redhat.com/show_bug.cgi?id=1510495
Comment 14Red Hat Bugzilla Rules Engine
2018-09-24 12:07:05 UTC
Development Management has reviewed and declined this request. You may appeal this decision by reopening this request.
Ok, I understand the proposed patch causes an issue. I think the fix in comment 12 (changing prints to log messages, allowing verbosity setting to quelch error messages) is a reasonable work around. Can that patch be merged into 7.5, pretty please?
Hi Robert,
I can't speak for CentOS, but if you wish to have the patch backported to RHEL-7.5, please consider opening a ticket with the customer support.
Thanks!
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...