Cron job log reads 'No MTA installed', does that prevent the CRON job from finishing?

Question

I have a cron job that is just running rsync on a particular directory.

When I run the rsync command itself sudo rsync -av --delete /directory1 /directory2, it runs without issue and does exactly as intended.

When the Cron job runs - I see it in /var/log/syslog.1 and it says this (summarized):

Mar  12 11:38:01 ip-xx-xx-xx-xxx CRON[4970]: (root) CMD (rsync --delete /my/directory /backup/directory)
Mar  12 11:38:01 ip-xx-xx-xx-xxx CRON[4970]: (CRON) info (No MTA installed, discarding output)

But the files are not in the backup directory (so it's not completing).

Does that second statement about 'No MTA installed' prevent the completion of the cron job? What is the best way to get that cron job to complete and get rid of the MTA error?

I found this answer but it doesn't say if that prevents the job from finishing.

Solution

No, it does not prevent the CRON job from finishing.

Normally, you shouldn't let your CRON job generate output without telling it where to write it. If you do, like in this case, CRON tries to mail it somewhere (also specified in the crontab file). If it doesn't succeed, it discards the output, as it says in the log file, and goes on.

In your case, you don't have a "Message Transfer Agent" installed. This is a generic name for packages, like postfix and ssmtp, that provide a mail command.

I recommend redirecting SYSOUT and SYSERR from the rsync command using > and 2>, respectively. If you're not interested at all, redirect output to /dev/null.

Comments

[goo]

Show us your crontab. Show us your script. No MTA installed makes me thing "No Mail Transfer Agent installed", and your cron job is trying to send mail (maybe just by writing to STDERR or STDOUT).

[Hanny]

How would I go about having it print to a log instead of trying to mail it?

[Jos]

sudo rsync -av --delete /directory1 /directory2 > /log/file 2> /log/errors. Use full path names to the log files. If you want regular output and errors to end up in the same file, use > /log/file 2>&1 rather than specifying the same file name twice.

[Hanny]

Excellent, thanks. Must be something strange in my cronjob then that's causing them to not actually finish (although I don't see any errors in the logs other than the MTA error); I don't see the 'copied' files.

[Jos]

As you are using the -v flag, rsync should report something about numbers of bytes sent/received, transfer speed, etc. That should be at the bottom of the log file. Also, if this is the literal command, rsync will create a directory /directory2/directory1 with the contents of the original directory1.

[Hanny]

It's run daily - so I'm going to set it to report to the logfile and give it a run. From the existing logfiles, it appears to be running, but when I go to the directory where I should find the files, it's empty.

[Hanny]

Jos - first I cd into /var/log and create the file: sudo touch cronlog; then I try to run the rsync with appropriate logs: sudo rsync -av --delete /dir1 /dir2 > /var/log/cronlog 2>&1 which is met with 'Permission denied'. I've tried creating the log file elsewhere but wind up with the same thing. Thoughts?

[Jos]

/var/log is a directory owned by the syslog group, and, as such, a bit tricky. Better create a log file in your home directory ( sudo rsync -av --delete /dir1 /dir2 > ~/mylogs/cronlog, sudo will be able to write there) or in /tmp.

[Hanny]

Let us continue this discussion in chat.

[Hanny]

On a side note: once I started logging the errors - I could see where it was failing. It said rsync could not use --delete without --recursive (-r) or --dirs (-d). I think that's what was causing it to fail - which I never would have noticed without seeing those errors! Thanks again!