Uploaded image for project: 'RHEL'
  1. RHEL
  2. RHEL-5372

[RFE] add -n option to crontab(5) to suppress mail when the run was successful

    • cronie-1.5.7-9.el9
    • Medium
    • rhel-sst-pt-python-ruby-nodejs
    • ssg_core_services
    • 20
    • None
    • Dev ack
    • False
    • Hide

      None

      Show
      None
    • None
    • None
    • If docs needed, set a value
    • None

      Description of problem:

      Managing the flow of email coming from cron(8) can be a challenge, especially when you manage a lot of machines. A pattern I see in system administration is that either a ton of logic is put in wrappers/scripts to sensibly deal with any output - or even worse all output is zapped with this dreaded pattern:

      • * * * * command_goes_here 2>&1 >/dev/null # piloting blind

      In the above example when your cron job fails, you will never know about it. You were depending on cron to backup some files? Screwed! The job has been failing due to filesystem permission errors for weeks - all your files are gone.

      There are workarounds for cron(8)'s shortcomings: you can either put logic in your scripts to only output when things went wrong, but then you'll not know about what didn't go wrong: "do x || echo error x".

      Another approach is to use wrappers that buffer all output until it is clear what the exit code of the underlaying command was, and then print the output so cron will email. Shims such as cronic or chronic are popular, but not part of base.

      To improve the situation I propose to add a simple crontab(5) convenience option called "-n" (mnemonic "No mail if run successful").

      With this "no mail if success" option you can do things like:

      • * * * * -n cp -rv src/ dest/

      With the above example crontab(5) entry you'll only receive a mail from cron(8) if the cp(1) encountered some kind of error. You'll also have in that email up until what point cp(1) actually was able to copy files.

      The "-n" option also encourages folks to be liberal with adding trace options to their shell scripts like "set -o errexit -o nounset -o xtrace", and just focus on making sure the script exits with a sensible exit code. This way when there is some kind of problem, you can read the full context from the cron mail and be more productive; and if there is no problem, you won't receive an email, reducing clutter in your inbox.

      Additional info: OpenBSD & NetBSD implemented this in their forks of vixie cron

      OpenBSD: Cover letter https://marc.info/?l=openbsd-tech&m=152874866117948&w=2 / commit: https://github.com/openbsd/src/commit/14eea8168449751553ba549cb1e8725fe289aeaf
      NetBSD: commit: https://github.com/NetBSD/src/commit/666eac5018f695be8449458fffd3de77d9305eb1

              opohorel@redhat.com Ondrej Pohorelsky
              jira-bugzilla-migration RH Bugzilla Integration
              Ondrej Pohorelsky Ondrej Pohorelsky
              Jan Houška Jan Houška (Inactive)
              Votes:
              2 Vote for this issue
              Watchers:
              17 Start watching this issue

                Created:
                Updated:
                Resolved: