Почему cron требует MTA для регистрации?

Почему cron требует MTA для регистрации? Есть ли какое-то конкретное преимущество в этом? Почему он не может создать файл журнала, как большинство других утилит?

Учтите, что традиционным «стандартным» способом регистрации данных является системный журнал , где метаданные, включенные в сообщения, представляют собой «код объекта» и уровень приоритета. Код объекта можно использовать для отделения потоков журнала от разных сервисов, чтобы их можно было разделить на разные файлы журнала и т. Д. (Хотя коды объекта несколько ограничены в том смысле, что они имеют фиксированные традиционные значения).

То, что не имеет системного журнала, это способ разделения сообщений для разных пользователей или от них, и это то, что cronнужно в традиционной многопользовательской системе. Бесполезно собирать сообщения от всех пользовательских заданий cron в общий файл журнала, где их может видеть только системный администратор. С другой стороны, электронная почта, естественно, предусматривает отправку сообщений различным пользователям, поэтому здесь это логичный выбор. Альтернативой было бы, чтобы cron выполнял работу вручную, и создавал лог-файлы для домашнего каталога каждого пользователя, но предполагалось, что традиционная многопользовательская система Unix будет иметь работающий MTA, поэтому реализация его в cron была бы в основном бесполезное упражнение.

Конечно, в современных системах возможны альтернативные варианты.

Я предполагаю, что под «ведением журнала» вы подразумеваете сохранение фактического вывода заданий. Ход работ уже регистрируется в журнале хрон в /var/cron/log(путь может отличаться между системами). Для этого журнала не требуется MTA.

Задание cron запускается как пользователь, чей crontab является частью задания.

В общем случае нет никакой гарантии, что этот пользователь сможет создавать файлы в системе (пользователь может не быть интерактивным пользователем), особенно за /varпределами иерархии, в которой обычно создаются журналы. Поэтому самый безопасный способ уведомить пользователя об ошибках и других результатах работы - это собрать их и отправить пользователю по электронной почте. Это также позволило бы пользователю настроить перенаправление электронной почты для учетной записи, чтобы иметь возможность видеть, например, ошибки в своем предпочтительном местоположении.

Если пользователь хочет сохранить вывод задания в файл, он может сделать это с помощью простого перенаправления в crontab:

0 */2 * * * "$HOME/scripts/myscript" >"$HOME/logs/myscript.log" 2>&1

Это будет выполняться "$HOME/scripts/myscript"каждый второй час в час и сохранять все выходные данные в "$HOME/logs/myscript.log". При выполнении этого задания электронные письма не будут создаваться, так как весь вывод перенаправлен. Без этого 2>&1сообщения об ошибках все равно будут отправляться по электронной почте.

Это позволяет пользователю выбирать, куда идет вывод.