cron jobs fail silently if too much output produced and no MTA is installed
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:
for (( i=0; i<634; i++ )); do
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.
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.
:: WORKAROUND ::
define MAILTO to empty (MAILTO="") at the beginning of the crontab .
|Changed in cron:|
|importance:||Undecided → Low|
|status:||Confirmed → Triaged|
|Changed in cron (Ubuntu):|
|status:||Triaged → Fix Released|