Это действительно распространенный антипаттерн, к которому склонны обращаться с cron.
Cron отправляет вам электронное письмо с выводом вашего скрипта, , если , то генерирует какой-либо вывод. Люди часто перенаправляют вывод на /dev/null, чтобы предотвратить отправку электронной почты cron. Это плохо, потому что теперь вывод вашего скрипта полностью потерян. Даже если в сценарии есть встроенная запись в журнал, он может генерировать ошибки, прежде чем он откроет файл журнала, и они будут потеряны. Он также может обработать sh способом, который не записывается в механизм ведения журнала.
Как минимум, вам нужно просто удалить 2>&1 >/dev/null, чтобы начать получать электронную почту. (а также, проверьте настройки почты, используя временное задание cron, например 1 * * * * echo "Test")
Следующее лучшее решение - изменить его на >> /var/log/myscript/current.log, а затем настроить что-то для вращения файлов журнала (например, logrotate), а также убедитесь, что создали этот каталог с разрешениями, которые пользователю сценария разрешено записывать в него. Путем только перенаправления STDOUT сценария любые ошибки или предупреждения, которые он записывает в STDERR, приводят к тому, что вы получаете электронное письмо, и если нет ошибок / предупреждений, вывод переходит в файл журнала, и электронное письмо не отправляется.
Однако ни одно из этих изменений не решает проблему root, заключающуюся в том, что когда cron запускает ваш скрипт, он делает это в среде, отличной от той, которая есть в командной строке. Что вам действительно нужно, так это способ запуска сценария в согласованной среде, и . «Окончательное решение» состоит в том, чтобы определить вашу задачу в каком-то диспетчере сервисов, а затем использовать cron, чтобы иногда запускать ее. Например, вы можете использовать systemd и определить службу, которая не перезапускается, а затем использовать systemctl start my_custom.service в вашем задании cron. Теперь вы можете выполнять тестирование независимо от cron, и ваши тесты будут иметь одинаковую среду и регистрироваться менеджером сервиса. В качестве дополнительных бонусов вы защищены от случайного запуска вашего скрипта два раза за раз, и вы получаете чистый способ остановить запущенную работу cron без опасности устаревших pid-файлов.
Я не особо поддерживаю systemd сам , но, к счастью, есть много альтернатив:
(но установка и настройка менеджера сервисов является более сложной задачей, чем просто использование systemd, если ваш дистрибутив основан на systemd) Каждый из них позволяет вам определить службу, которая не перезапускается. Затем вы используете команду оболочки для выдачи директивы «запустить один раз» супервизору, который запускает задачу как дочерний элемент. Теперь вы можете легко запустить задания самостоятельно и просмотреть все ошибки в журнале, а затем добавить эту команду в crontab и знать, что она будет работать одинаково при запуске cron.
Вернемся к исходной проблеме, один раз вы получаете некоторые записи, которые вы, вероятно, обнаружите, это проблема с правами доступа или обновленный модуль в системе perl.