cron jobs fail silently if too much output produced and no MTA is installed

Bug #151231 reported by Tim Reid on 2007-10-10
This bug affects 5 people
Affects Status Importance Assigned to Milestone
cron (Ubuntu)

Bug Description

Binary package hint: cron

If my cron job produces too much output, it fails silently. This appears to be well-defined and reproducible. The following cron line:

* * * * * /bin/bash -l -c "cd /home/tim/test && ./runme 2>err"

runs the following script:

#!/bin/bash -x

for (( i=0; i<634; i++ )); do
  printf "."


This successfully runs the 'touch' line and creates the file. However, when the "634" is changed to "635", the script fails to run to completion and the 'touch' line never executes. The stderr output indicates that the program terminates during the printf statement.

If I add two characters to the cron command:

* * * * * /bin/bash -l -c "cd /home/tim/./test && ./runme 2>err"

then the threshold drops by two: 632 succeeds, 633 fails.

I do not have mail installed on my box.

**Speculation follows**

I'm guessing that what's going on here is this: cron starts the job with the output piped (probably indirectly) into mail. However, 'mail' doesn't exist, as I haven't installed it, so the pipe isn't created properly. However, as the output is buffered, everything continues normally until the job has produced enough output to fill the buffer. The operating system tries to write the buffer into the (broken) pipe and fails (with a signal?) which terminates the process. If little or no output is produced by the job, the buffer flush doesn't happen until the process is terminating, so from the user's point of view, it terminates normally.

Part of the usual cron-generated email contains the command executed. Consequently, for a longer command there is less space left in the unflushed buffer so less output is required from the process before it fails.


If my speculation is correct, there seem to be two main options:

  1) cron should check whether its call to the 'mail' program succeeded, and if not, simply discard the job's output, or
  2) mail should be made a prerequisite for the cron package.

For a small machine, like mine, I'm not planning to install any more packages than strictly necessary, so I'd prefer option 1). This way, cron jobs would run reliably, it's just that I wouldn't get mail notifications with output, errors, and so on.

define MAILTO to empty (MAILTO="") at the beginning of the crontab .

Related branches

CVE References

Jean-Baptiste Lallement (jibel) wrote :

Thanks for your report.

I've increased the counter to 99999. It's working when an MTA is installed but fails after uninstalling it.

A workaround is to define MAILTO to empty (MAILTO="") at the beginning of the crontab.

Changed in cron:
status: New → Confirmed
Aleksander Demko (ademko) wrote :

Yes, the MAILTO workaround seems to work, but must be added to each user's crontab (including root's).

I guess I'll reinstall postfix, as that seems like less work :)

Jean-Baptiste Lallement (jibel) wrote :

Even if there is a workaround this is a bug in cron indeed. So I don't close this report and leave it "confirmed" for now.

Regarding the MAILTO, I think you can set it globally in /etc/default/cron . This file is parsed in cron's init script and will be inherited by cron and it's children.

I hope this helps.

description: updated
Changed in cron:
importance: Undecided → Low
status: Confirmed → Triaged

I've had this problem for a few months now. Some of my cron jobs run, and some of them don't (quite randomly). I'll try this workaround and see if that does it, because I know my jobs do generate output.

Funny thing is, the cron I was using with gentoo never had this problem with the same set of scripts...

nglnx (nglnx) wrote :

Even if you considere this a bug in cron, it was Ubuntu's decision to ship the Desktop version without a MTA installed by default (a decision that I am not questioning, since I agree with it).

Debian ships a MTA installed by default (exim, AFAIK) so this issue does not manifest itself there . You also have to take into account that this is a program that has been in maintenance mode for many years.

What we can't have is incoherent beahavior, whereby a cron job might fail in an Ubuntu Desktop depending on how big the output it produces is. Cron is one of those programs a user expects to behave consistently among different distros and versions.

If the issue can't be solved upstream in a reasonable time frame, it should be addressed in Ubuntu.

arrange (samozrejmost) wrote :

Another workaround is to redirect the output of the script, either to a log file, or simply to /dev/null.

Launchpad Janitor (janitor) wrote :
Download full text (11.3 KiB)

This bug was fixed in the package cron - 3.0pl1-113ubuntu1

cron (3.0pl1-113ubuntu1) maverick; urgency=low

  * Merge from debian unstable. Fixes:
    - LP: #46493 (this should have been fixed way back in 3.0pl1-87, and I
      confirmed it is no longer a problem)
    - LP: #118168 (Debian #79037)
    - LP: #151231 (Debian #155109, #443615)
    - LP: #308341 (Debian #437180)
  * Remaining changes:
    - debian/control:
      + Build-Depends on debhelper >= 7.3.15ubuntu2, for Upstart
      + Drop MTA and lockfile-args to Suggests
    - add debian/cron.upstart
    - debian/postinst: remove calls to update-rc.d, invoke-rc.d and
    - debian/postrm: remove call to update-rc.d
    - debian/prerm: remove calls to invoke-rc.d and /etc/init.d/cron
    - debian/rules: install Upstart job
  * Drop the following changes, now in debian:
    - popen.c: check return code of initgroups() in cron_popen()
    - debian/control: add missing ${misc:Depends}
    - debian/control: Depends bump on lsb to >= 3.2.12ubuntu2. No longer
      required now that we use Upstart
    - debian/cron.pam: switch from including common-session to including
      the new common-session-noninteractive
    - pathnames.h: use sensible-editor

cron (3.0pl1-113) unstable; urgency=medium

  [ Christian Kastner / Javier Fernandez-Sanguino ]
  * debian/postinst:
    - Now that permissions and ownership of crontabs are changed unconditionally,
      do not attempt to chown user crontabs if none are present. Closes: #585636
    - Only change permissions if the crontabs directory exist

cron (3.0pl1-112) unstable; urgency=low

  [ Christian Kastner ]
  * do_command.c:
    - Don't send mail when a job exits non-zero, only send mail if the job sent
      output to stderr. This behaviour was introduced erroneously; while it
      does have merit, it is completly against standard cron behaviour.
      Closes: #581612
  * debian/compat:
    - Bumped debhelper compatibility to 7
  * debian/control:
    - Bumped Standards-Version to 3.8.4 (no change needed)
    - Build-Depend on debhelper (>= 7.0.50~)
    - Added dependency on ${misc:Depends} to package cron
  * debian/cron.init:
    - Changed Default-Stop from (1) to (empty). rc0 and rc6 were removed in
      3.0pl1-101 because the stop action -- sending SIGTERM/SIGKILL to cron
      on shutdown/reboot -- was redundant. This, however, also applies to
      rc1, because killprocs will do that for us.
  * debian/postinst:
    - Removed obsolete dpkg file backup code, this has been handed over to dpkg
      in 3.0pl1-109
    - Removed last remaining stop action (for rc1) from upate-rc.d (see above)
    - Add dpkg-statoverride for /usr/bin/crontab, and unconditionally change
      permissions of /var/spool/cron/crontabs. Closes: #304036, #460095
  * debian/standard.monthly:
    - Removed because it had been empty for years and therefore served no
  * debian/cron.bug-{control,script}
    - Added to extend information submitted by reportbug
  * debian/rules:
    - Applied changes for standard.monthly and cron.bug-{control,script} above
  * debian/copyright:
    - Updated to reflect recent contribution...

Changed in cron (Ubuntu):
status: Triaged → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers