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
Another workaround is to redirect the output of the script, either to a
log file, or simply to /dev/null.
--
cron jobs fail silently if too much output produced and no MTA is installed
https://bugs.launchpad.net/bugs/151231
You received this bug notification because you are a member of Ubuntu
Bug
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
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 s
** Changed in: cron (Ubuntu)
Importance: Undecided => Low
Status: Confirmed => Triaged
--
cron jobs fail silently if too much output produced and no MTA is installed
https://bugs.launchpad.net/bugs/151231
You received this bug notification because you are a member of Ubuntu
Bugs, which
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
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 :)
--
cron jobs fail silently if too much output produced
https://bugs.launchpad.net/bugs/151231
You received this bug notification
Thanks for your report.
I've increased the counter to 9. 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 (Ubuntu)
Status: New => Confirmed
--
cron jobs f
