Why does cron require MTA for logging? Is there any particular advantage to this? Why can't it create a log file like most other utilities?
Why does cron require MTA for logging
cronemaillogsnetworking
Related Solutions
Base on this answer from ServerFault,
ufw supports per rule logging. By default, no logging is performed when a packet matches a rule.
All you have to do is create a UFW deny rule to match those multicast packets.
On Unix the mail system is the means by which system notifications get delivered to users. You can think of it as sort of like on Windows where something will show in your taskbar with a popup message if it needs to notify you of something. Since cronjobs (theoretically) shouldn't produce any output (since no one should be there to see it) any output (stdout or stderr) is treated as if it's a possible indication of an error or issue and so an email is sent to the cronjob's owner to prompt them to check it out.
So, all output (stdout and stderr) is sent through the local mail system to the cronjob's owner. If the owner is a non-personal account you can direct the local MTA to relay to a real email account by setting up an alias. For example, I added to /etc/aliases:
root: joel.davis@xxx.com
Then ran the newaliases command (to rebuild mail aliases database). After that, I started to receive root's email's in my corporate email's inbox:
root@xxxxxxvlp05 ~ $ echo "the game" | mutt root -s "No Diggity"
sendmail: warning: inet_protocols: IPv6 support is disabled: Address family not supported by protocol
sendmail: warning: inet_protocols: configuring for IPv4 support only
postdrop: warning: inet_protocols: IPv6 support is disabled: Address family not supported by protocol
postdrop: warning: inet_protocols: configuring for IPv4 support only
So that's the more or less normal way (letting the system send notification emails). There are other means of dealing with the notification. A few alternatives:
Modifying aliases to save the emails to a particular file:
root: /var/log/rootMails
Piping the mail to a script:
root: |/usr/local/bin/filterMail
An alternative to messing with aliases is to use the MAILTO= option inside the user's crontab that many cron daemons support. This might be preferable if you only want to receive a particular set of the user's notifications, and not anything that will get dropped into their mailbox (which is what aliases accomplishes).
I'm sure there are plenty of others, but you probably want to do the first or last ones, though.
Best Answer
Consider that the traditional "standard" way of logging data is syslog, where the metadata included in the messages are the "facility code" and the priority level. The facility code can be used to separate log streams from different services so that they can be split into different log files, etc. (even though the facility codes are somewhat limited in that they have fixed traditional meanings.)
What syslog doesn't have, is a way to separate messages for or from different users, and that's something that
cronneeds on a traditional multi-user system. It's no use collecting the messages from all users' cron jobs to a common log file where only the system administrator can see them. On the other hand, email naturally provides for sending messages to different users, so it's a logical choice here. The alternative would be for cron to do the work manually, and to create logfiles to each users' home directory, but a traditional multi-user Unix system would be assumed to have a working MTA, so implementing it in cron would have been mostly a futile exercise.On modern systems, there might be alternative choices, of course.