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.
** Summary changed:
- cron jobs fail silently if too much output produced
+ cron jobs fail silently if too much output produced and no MTA is installed
** Description changed:
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 "."
done
touch got.here
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.
**Suggestions**
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.
+
+ :: WORKAROUND ::
+ define MAILTO to empty (MAILTO="") at the beginning of the crontab .
--
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 is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
