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