Bug 1690538
| Summary: | rear cron first time run triggers a cron mail with error in mail body | |||
|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Oliver Falk <ofalk> | |
| Component: | rear | Assignee: | Vitezslav Crhonek <vcrhonek> | |
| Status: | CLOSED WONTFIX | QA Contact: | BaseOS QE - Apps <qe-baseos-apps> | |
| Severity: | medium | Docs Contact: | ||
| Priority: | unspecified | |||
| Version: | 7.6 | CC: | fkrska, ovasik, pcahyna, peter.vreman, vcrhonek, vdolezal | |
| Target Milestone: | rc | |||
| Target Release: | --- | |||
| Hardware: | All | |||
| OS: | Linux | |||
| Whiteboard: | ||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | ||
| Doc Text: | Story Points: | --- | ||
| Clone Of: | ||||
| : | 1729499 (view as bug list) | Environment: | ||
| Last Closed: | 2020-11-11 21:55:03 UTC | Type: | Bug | |
| Regression: | --- | Mount Type: | --- | |
| Documentation: | --- | CRM: | ||
| Verified Versions: | Category: | --- | ||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
| Cloudforms Team: | --- | Target Upstream Version: | ||
| Embargoed: | ||||
| Bug Depends On: | ||||
| Bug Blocks: | 1122832, 1729499 | |||
I looked at exactly that cron job very recently and thought that it is quite strange to enable this unconditionally. I will think about what can be done. Pavel, great you already assigned this to you. I guess a simple if-statement around that cron job would be sufficient to eliminate the error mail. Oliver, I was thinking more about the issue and it is not clear to me that there is a real problem. Why is it a bad thing that a backup tool reminds the administrator that it needs to be configured and properly run first in order to be of any use? Pavel, you're right. It's not a _real_ problem, however, imagine you deploy rear on hundreds of machines and want to continue the configuration on the next day, you'll receive hundreds of mails in the night. Maybe not what you want. And even funnier, after the first "error"-mail, you no longer receive an e-mail. I guess you know what I mean? :-) I guess changing the command to test -f /var/lib/rear/layout/disklayout.conf && /usr/sbin/rear checklayout || /usr/sbin/rear mkrescue should do the trick. Or maybe we can comment out that line so it isn't enabled by default? Note: that cron file comes from the upstream .spec file and it has already been removed upstream: https://github.com/rear/rear/commit/89a8f18ec402b439caf4800421644f5bf5d174e5 (see referenced issue for more info) IMHO. If we remove that cron we'll run into the following issues: *) Users who are used to have that cron in place, suddenly don't get it any longer. *) ^^^ leads to: Requires work on the user end. If we comment out the line we'll run into two other issues: *) Requires more work on the user end: Enable it for (potentially) hundreds of systems. *) ^^^ leads to: In case we decide to update something in that file at some point in time, the struggle with .rpmnew ... In both scenarios: *) I don't think these are changes we want to introduce in the current life cycle phase of RHEL7. *) It requires more work on the user end + docs (/release notes). *) As Pavel pointed out, fixing this in RHEL8, but not in RHEL7, would lead to deviation between RHEL7 and RHEL8 (and actually not fix the issue in RHEL7, which we'll have to support for a few more years; Think ELS). If we adapt the line, as Vaclav suggested, I guess that is the better user experience. My 2 cents, Oliver The upstream proposal of the systemd code has the same error, that the command will fail with exit code 1. So the systemd also requires to replace the logical of '||' a 'if ... then ...; fi' to not fail with exit code 1. Red Hat Enterprise Linux 7 shipped it's final minor release on September 29th, 2020. 7.9 was the last minor releases scheduled for RHEL 7. From intial triage it does not appear the remaining Bugzillas meet the inclusion criteria for Maintenance Phase 2 and will now be closed. From the RHEL life cycle page: https://access.redhat.com/support/policy/updates/errata#Maintenance_Support_2_Phase "During Maintenance Support 2 Phase for Red Hat Enterprise Linux version 7,Red Hat defined Critical and Important impact Security Advisories (RHSAs) and selected (at Red Hat discretion) Urgent Priority Bug Fix Advisories (RHBAs) may be released as they become available." If this BZ was closed in error and meets the above criteria please re-open it flag for 7.9.z, provide suitable business and technical justifications, and follow the process for Accelerated Fixes: https://source.redhat.com/groups/public/pnt-cxno/pnt_customer_experience_and_operations_wiki/support_delivery_accelerated_fix_release_handbook Feature Requests can re-opened and moved to RHEL 8 if the desired functionality is not already present in the product. Please reach out to the applicable Product Experience Engineer[0] if you have any questions or concerns. [0] https://bugzilla.redhat.com/page.cgi?id=agile_component_mapping.html&product=Red+Hat+Enterprise+Linux+7 |
Description of problem: When installing rear without configuring, it triggers an e-mail via cron in the night with an error message. Version-Release number of selected component (if applicable): - How reproducible: Always. Steps to Reproduce: 1. Install rear # sudo yum install -y rear 2. Run the content that is listed in cron (/etc/cron.d/rear) # /usr/sbin/rear checklayout || /usr/sbin/rear mkrescue If you want to reproduce it after that: # sudo rm -rf /var/lib/rear/layout Actual results (on command line and in the cron mail): # /usr/sbin/rear checklayout || /usr/sbin/rear mkrescue ERROR: No (non-empty) /var/lib/rear/layout/disklayout.conf file (needs to be created before e.g. via 'rear mkrescue/mkbackup') Aborting due to an error, check /var/log/rear/rear-xxx.log.lockless for details Terminated Expected results: No error should be triggered. Additional info: Customer case will be attached.