Disable cron emails (solution)

December 11, 2023 by Hayden James, in Blog Linux

This article lists three common methods to disable cron emails and another solution to send emails only when errors occur. Cron is a daemon that executes scheduled commands. More specifically, the software utility cron is a time-based job scheduler for Unix-like operating systems like Linux.

You can use cron to set up jobs to run periodically at fixed times, dates, or intervals. Cron is an extremely powerful tool because just about anything you can type from the command line can be scheduled using cron.

Table of Contents

Why Disable cron emails?

disable cron emails cronic

Cron’s automatic email feature is a double-edged sword. While it conveniently sends outputs of cron jobs via email, it can lead to an overwhelming influx of repetitive or duplicate messages. This can clutter your inbox, making it challenging to identify important emails.

To manage this, you might consider either reducing the frequency of these notifications or disabling them entirely. This approach helps streamline your email management, ensuring that only essential communications capture your attention, which is particularly beneficial in a busy IT environment.

Method 1: Redirecting Output to Null

We can disable cron emails by adding >/dev/null 2>&1 to the end of each cron job line. For example:

0 1 * * * mycommand >/dev/null 2>&1

A quick breakdown of >/dev/null 2>&1:

> = redirect.

/dev/null = a device file location in Unix systems that discards any data written to it.

2>&1 = redirects stderr (standard errors) and stdout (standard output).

This results in both the Standard Error and Standard Out being redirected to /dev/null, rather than sent by email.

Method 2: Adjusting the MAILTO Variable

For cron, the default value of MAILTO is root. We can change the root value of the MAILTO variable via the /etc/crontab config file to "" (blank). Example:

MAILTO=""

This disables cron daemon’s emails.

Method 3: Using CRONDARGS for Advanced Control

If you disable cron emails completely and something goes wrong, you will lose the output. You can get around this by setting CRONDARGS string. For example:

CRONDARGS= -s -m off

-s = forwards the output to system log.

-m off = disables cron emails.

On RHEL/Fedora, you can edit /etc/sysconfig/crond. So that it looks similar to:

# Settings for the CRON daemon.
# CRONDARGS= : any extra command-line startup arguments for crond
CRONDARGS= -s -m off

For Debian/Ubuntu, you can edit using:

systemctl edit --full cron.service

Method 4: Error-Only Notifications with Cronic

Cronic is a small shell script for wrapping cron jobs so that cron will only send an email when an error has occurred. Cronic defines an error as any non-trace error output or a non-zero result code. Example usage:

0 1 * * * cronic mycommand

Conclusion

There are a couple of ways to disable cron emails. However, unless you want to stop emails completely, I recommend starting with cronic. If you forward cron output to system logs instead, be careful not to flood logs by creating very frequent writes to your log file.

Managing cron emails effectively enhances your system’s efficiency and keeps your inbox clutter-free. Whether you choose to disable these emails entirely or selectively reduce their frequency, the methods outlined offer practical solutions tailored to your specific needs. Ultimately, the right approach depends on your unique operational requirements and preferences, ensuring that you receive only the most relevant notifications.

Published: Jun 10, 2020 | Last update: December 21, 2023

Tags: scripts, server, sysadmins

Discussion

couldn’t you use cron -L and follow the instructions in crontab (1 & 5) man pages?
And Debian uses it’s own version , See cron (8) man page “Debian Specific” section:
DEBIAN SPECIFIC
Debian introduces some changes to cron that were not originally avail-
able upstream. The most significant changes introduced are:

   —      Support    for    /etc/cron.{hourly,daily,weekly,monthly}    via
          /etc/crontab,

   —      Support for /etc/cron.d (drop-in dir for package crontabs),

   —      PAM support,

   —      SELinux support,

   —      auditlog support,

   —      DST and other time-related changes/fixes,

   —      SGID crontab(1) instead of SUID root,

   —      Debian-specific file locations and commands,

   —      Debian-specific configuration (/etc/default/cron),

   —      numerous other smaller features and fixes.

   Support  for  /etc/cron.hourly,  /etc/cron.daily,  /etc/cron.weekly and
   /etc/cron.monthly is provided in Debian through the default setting  of
   the /etc/crontab file (see the system-wide example in crontab(5)).  The
   default system-wide crontab contains four tasks: run every hour,  every
   day, every week and every month.  Each of these tasks will execute run-
   parts providing each one of the  directories  as  an  argument.   These
   tasks are disabled if anacron is installed (except for the hourly task)
   to prevent conflicts between both daemons.

   As described above, the files under these directories have to pass some
   sanity checks including the following: be executable, be owned by root,
   not be writable by group or other and,  if  symlinks,  point  to  files
   owned  by root.  Additionally, the file names must conform to the file-
   name requirements of run-parts: they must be entirely made up  of  let-
   ters,  digits  and can only contain the special signs underscores ('_')
   and hyphens ('-').  Any file that does not conform  to  these  require-
   ments  will  not  be executed by run-parts.  For example, any file con-
   taining dots will be ignored.  This is done to prevent cron  from  run-
   ning  any  of  the files that are left by the Debian package management
   system when handling files in /etc/cron.d/ as configuration files (i.e.
   files ending in .dpkg-dist, .dpkg-orig, .dpkg-old, and .dpkg-new).

   This  feature  can be used by system administrators and packages to in-
   clude tasks that will be run at defined intervals.   Files  created  by
   packages  in  these  directories should be named after the package that
   supplies them.

   Support for /etc/cron.d is included in the cron  daemon  itself,  which
   handles this location as the system-wide crontab spool.  This directory
   can contain any file  defining  tasks  following  the  format  used  in
   /etc/crontab, i.e. unlike the user cron spool, these files must provide
   the username to run the task as in the task definition.

   Files in this directory have to be owned by root, do not need to be ex-
   ecutable  (they  are  configuration  files, just like /etc/crontab) and
   must conform to the same naming convention as used  by  run-parts(8)  :
   they  must consist solely of upper- and lower-case letters, digits, un-
   derscores, and hyphens.  This means that they cannot contain any  dots.
   If the -l option is specified to cron (this option can be setup through
   /etc/default/cron, see below), then they must conform to the LSB  name-
   space  specification,  exactly  as  in  the --lsbsysinit option in run-
   parts.

   The intended purpose of this feature is to allow packages that  require
   finer      control      of      their      scheduling      than     the
   /etc/cron.{hourly,daily,weekly,monthly} directories to  add  a  crontab
   file to /etc/cron.d.  Such files should be named after the package that
   supplies them.

hydn

Thanks for sharing this @tmick

View comments