Отключить электронные письма cron, если нет ошибок?

Как я могу получать электронные письма только от cron, если есть ошибки?

В подавляющем большинстве случаев задачи будут выполняться просто отлично, и мне действительно наплевать на результат.

Это только в редком случае сбоя, который я хочу / должен знать.

У меня есть procmail в наличии - но я не уверен, что то, что я описываю, возможно для внешнего управления cron "правильно".

Поскольку вы не заботитесь о выводе, вы можете перенаправить STDOUT задания /dev/nullи разрешить отправку STDERR по почте (используя MAILTOпеременную окружения).

Так, например:

...
...
MAILTO=foobar@example.com
...
...
* * * * * /my/script.sh >/dev/null

отправит почту, когда будет вывод только на STDERR (с STDERR), и отменит STDOUT.

Это, конечно, предполагает, что когда программа написала на STDERR, произошел сбой; это может быть не всегда так. Если у вас есть контроль над программой, вы можете сделать это. Для любого сложного случая вы должны написать какую-нибудь оболочку, которая запускает команду (и) и отправлять почту соответственно. И положить обертку как cronработу.

Команда chronicот moreutils выполняет команду тихо, если она не терпит неудачу.

Цитирую из своего руководства:

Хроник запускает команду и организует отображение ее стандартного выхода и стандартной ошибки только в случае сбоя команды (выход из ненулевого значения или сбой). Если команда выполнена успешно, любой посторонний вывод будет скрыт.

Обычное использование хронического - для выполнения задания cron. Вместо того чтобы держать команду в секрете и иметь дело с письмами, содержащими случайный вывод при успешном выполнении и недостаточно подробный вывод при сбое, вы можете просто выполнить его подробно и использовать хронический, чтобы скрыть успешный вывод.

Как я могу получать электронные письма только от cron, если есть ошибки?

Вы можете обернуть свои вызовы cron с помощью cronic , сценария оболочки, который использует вывод cron, если только код возврата вызванного процесса не равен нулю или не выводится ошибка трассировки.

Чтобы использовать cronic, загрузите скрипт в подходящее место, например /usr/local/bin. Перед вашими записями в crontab должен быть указан путь к сценарию (например /usr/local/bin/cronic), или просто cronic, при условии, что вы PATHправильно настроены.

Обратите внимание, что «ошибки» - это плохо сформулированный термин в вашем вопросе и требует тщательного определения. Чтобы cronic был полезен, необходимо убедиться, что задания, которые вы переносите с ошибками отчета cronic, одним из способов определения состояния ошибки. Неявные методы отчетности, такие как написание текстовых строк STDOUT, потребуют дальнейших размышлений, чтобы сделать это совместимым с хроническим или другим механизмом отчетности хрон.

Другие обертки доступны, как указано на сайте cronic:

• зашикать
• Cronwrap

Вот еще один вариант, который я успешно использовал в течение многих лет - захватывать вывод и распечатывать его только при ошибке . Это не требует временных файлов и сохраняет весь вывод . Важной частью является то, 2>&1что перенаправляет STDERR на STDOUT.

Отправьте весь вывод через конфигурацию cron mailer по умолчанию:

1 2 * * * root OUTPUT=`flexbackup -set all 2>&1` || echo "$OUTPUT"

То же самое, но с конкретным адресом и темой:

1 2 * * * root OUTPUT=`flexbackup -set all 2>&1` || echo "$OUTPUT" | mail -s "Failed to backup" an@email.address

Вы даже можете выполнить несколько действий в случае ошибки и добавить в электронную почту:

1 2 * * * root OUTPUT=`flexbackup -set all 2>&1` || {echo "$OUTPUT" ; ls -ltr /backup/dir ; }

Это будет работать для простых команд. Если вы имеете дело со сложными каналами ( find / -type f | grep -v bla | tar something-or-other), то вам лучше переместить команду в сценарий и запустить сценарий, используя вышеупомянутый подход. Причина в том, что если какая-либо часть канала будет выводиться в STDERR, вы все равно будете получать электронные письма.

Я, вероятно, не думал об этом все время, но

* * * * * yourthing.sh >/tmp/yourthing.log && rm -f /tmp/yourthing.log; cat /tmp/yourthing.log 2>/dev/null

в обычных случаях перенаправит все во временный файл (вы, вероятно, захотите использовать mktempдля получения уникального имени файла), удалите его, если файл был успешным, и затем catснова содержимое, если они все еще существуют (то есть, с выходом yourthing.sh с ошибочным условием), чтобы быть поднятым cron mailer.

Если память служит, cron уже ничего не отправляет, если не было вывода, поэтому, если файл журнала пуст или не существует, ничего не происходит. (Мы перенаправляем сообщение об ошибке.)