Почему 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сообщения об ошибках все равно будут отправляться по электронной почте.
Это позволяет пользователю выбирать, куда идет вывод.