Por que o cron requer MTA para log? Existe alguma vantagem específica nisso? Por que ele não pode criar um arquivo de log como a maioria dos outros utilitários?
Respostas:
Considere que a maneira "padrão" tradicional de registrar dados é syslog , onde os metadados incluídos nas mensagens são o "código da instalação" e o nível de prioridade. O código da instalação pode ser usado para separar fluxos de logs de diferentes serviços, para que possam ser divididos em diferentes arquivos de registro etc. (mesmo que os códigos da instalação sejam um pouco limitados, pois eles têm significados fixos tradicionais).
O que o syslog não possui é uma maneira de separar mensagens para ou de usuários diferentes, e isso é algo que cronprecisa em um sistema multiusuário tradicional. Não adianta coletar as mensagens dos trabalhos cron de todos os usuários em um arquivo de log comum, onde apenas o administrador do sistema possa vê-las. Por outro lado, o email naturalmente fornece o envio de mensagens para diferentes usuários, por isso é uma escolha lógica aqui. A alternativa seria que o cron fizesse o trabalho manualmente e criasse arquivos de log no diretório inicial de cada usuário, mas presume-se que um sistema Unix tradicional para vários usuários possua um MTA funcional, portanto, implementá-lo no cron seria principalmente um exercício fútil.
Nos sistemas modernos, pode haver escolhas alternativas, é claro.
Suponho que, por "log", você queira armazenar a saída real dos trabalhos. A execução de tarefas já está registrada no log do cron /var/cron/log(o caminho pode variar entre os sistemas). Não há MTA necessário para esse log.
Uma tarefa cron é executada como o usuário do qual a parte crontab da tarefa faz parte.
No caso geral, não há garantia de que este usuário possa criar arquivos no sistema (um usuário pode não ser um usuário interativo), especialmente fora da /varhierarquia em que os logs geralmente são criados. A maneira mais segura de notificar o usuário sobre erros e outras saídas de um trabalho é, portanto, coletá-los e enviá-los por e-mail ao usuário. Isso também permitiria ao usuário configurar o redirecionamento de e-mail para que a conta pudesse ver, por exemplo, erros no local preferido.
Se o usuário quiser salvar a saída de uma tarefa em arquivo, poderá fazê-lo com um redirecionamento simples no crontab:
0 */2 * * * "$HOME/scripts/myscript" >"$HOME/logs/myscript.log" 2>&1
Isso seria executado a "$HOME/scripts/myscript"cada segunda hora, a cada hora, e salvaria toda a saída em "$HOME/logs/myscript.log". Nenhum e-mail seria criado executando este trabalho, pois toda a saída é redirecionada. Sem isso 2>&1, as mensagens de erro ainda seriam enviadas por email.
Isso permite que o usuário escolha para onde vai a saída.