Fix “No MTA installed, discarding output” in cron

The message means cron collected output from a job but could not send it through a local mail transport agent (MTA). It does not establish whether the job succeeded: both successful commands and failed commands can produce output.

First recover useful evidence by giving the output a destination. Then decide whether email is part of your monitoring design.

Save both output streams

For a user crontab, a job that runs every ten minutes can append its output to a file:

*/10 * * * * /app/jobs/backup.sh >> /var/log/backup.log 2>&1

Provision the directory and file so the job's account can write them. The shell opens the log before starting the command; a permissions failure can prevent the job from starting at all. >> preserves existing content, and 2>&1 sends standard error to the same destination.

Give the log a retention policy. For example, a logrotate rule can retain four weekly rotations:

/var/log/backup.log {
    weekly
    rotate 4
    compress
    missingok
    notifempty
}

Configure the new file's ownership for the job account in your environment. A process that keeps the file open across rotation may continue writing to the old file until it reopens it. Verify rotation and collection with an actual test message.

For several hosts, Guance log collection can bring these files into one place. Include a job name, run identifier, and completion status so that output can be associated with a particular execution.

Configure mail when you want email

On Debian or Ubuntu, one lightweight option is msmtp with its sendmail-compatible package:

sudo apt install msmtp msmtp-mta

Installation alone does not configure delivery. Set the SMTP server, TLS and authentication according to your mail provider, restrict access to credentials, and test delivery as the job account. Then select a recipient in the crontab:

MAILTO="ops@example.com"
0 3 * * * /app/jobs/backup.sh

Cron normally mails unredirected output. A silent command that exits nonzero may generate no email, while a successful command that prints a status message may generate one. Redirecting only standard output leaves standard error available for mail, but that is not the same as “email only on failure.” Use a wrapper that checks the exit status for that behavior.

Consider a systemd timer

On a systemd host, a service can keep output in the journal. Create backup.service with the appropriate account:

[Service]
Type=oneshot
User=backup
ExecStart=/app/jobs/backup.sh

Pair it with backup.timer:

[Timer]
OnCalendar=*-*-* *:0/10:00

[Install]
WantedBy=timers.target

After saving both under /etc/systemd/system/, reload the units and enable the timer:

sudo systemctl daemon-reload
sudo systemctl enable --now backup.timer
journalctl -u backup.service

Validate the account and script before enabling it. Review the service journal for job output; the timer unit mainly describes scheduling.

Common questions

Does MAILTO="" fix the warning? It disables cron mail for the following jobs, but does not preserve their output. Arrange another output destination first.

Should I discard output with /dev/null? Only when that output is deliberately unnecessary and another mechanism records failures and missed completions.

Is this a cron scheduling error? The warning concerns output delivery. Investigate scheduling, command exit status, and mail delivery as separate questions.

References

• Debian crontab mail settings
• systemd timer reference