Лучшие практики для поддержки cronjobs и сценариев оболочки?

Не полный ответ, а дополнительные полезные ресурсы: http://blog.endpoint.com/2008/12/best-practices-for-cron.html

Я потихоньку прохожу через это, и пытаюсь реализовать каждый из пунктов. Я не думал гуглить «лучшие практики cron» до моего поста. :П

Для управления версиями я пока собираюсь использовать RCS, так как редактирую скрипты пофайлово, но мне посоветовали настроить Git (или Mercurial, если я работал в системе Windows). ).

Звучит здорово: http://everythingsysadmin.com/2010/09/xed-202-released.html «xed — это perl-скрипт, который блокирует файл, запускает $EDITOR для файла, а затем разблокирует его»… и помещает его в RCS, если это еще не было сделано. Полностью безмозглый контроль версий. Если я разберусь с bash, я хотел бы создать ярлык редактирования, который автоматически фиксирует любую систему контроля версий, которую я использую.

Другие советы, которые я получил от системного администратора, Даты: вместо того, чтобы использовать, скажем, дату или --date="последний понедельник", используйте фиксированную дату и добавляйте к ней день/неделю и т. д. каждый раз, когда она запускается (если не более текущий день, очевидно), потому что тогда, если скрипт не запускается, я могу просто перезапускать скрипт несколько раз, пока он не наверстает упущенное. Ах! (И это может показаться очевидным, но куча отчетов, которые я буду редактировать, не говорите явно, за какие даты работает отчет. Исправим.)

И меня заверили, что я должен попытаться сделать электронные письма cron как можно более тихими, чтобы я действительно заметил, есть ли электронное письмо с ошибкой. Существуют оболочки для улучшения отчетов об ошибках cron, которые я еще не исследовал, ссылки здесь: http://habilis.net/cronic/

Перед вами стоит сложнейшая задача, удачи. :)

Я бы предложил найти все задачи, которые выполняются ежедневно, и запихнуть их в свои скрипты в /etc/cron.daily/. То же самое для недели в /etc/cron.weekly, часа и месяца.

Возможно, вы захотите изучить использование anacron(8) для планирования ваших заданий, если машина не всегда будет подключена к сети, но вам все же нужен некоторый уровень контроля над запуском заданий. Это был cron-helper-tool по умолчанию для нескольких дистрибутивов в течение нескольких лет, так что, надеюсь, он достаточно стабилен, чтобы полагаться на ваши собственные задачи; но я легко мог себе представить, что это может не совсем соответствовать вашим потребностям.

Подделать даты для скриптов можно как минимум с двумя пакетами в Ubuntu: datefudge и faketime. У меня нет опыта ни с тем, ни с другим, но оба звучат так, как будто они должны быть в состоянии помочь. Надеюсь, в будущем он вам не понадобится. :)

Извините, я не знаю средства проверки пути для bash-скриптов. Это кажется маловероятным, поскольку простые скрипты просты и их легко проверить на глаз :), а сложные скрипты все равно будут генерировать свои пути во время выполнения. Возможно, вы могли бы вести базу данных путей, используемых каждым сценарием, и написать новый сценарий для регулярной проверки этой базы данных.

Вы можете отключить электронную почту cron, установив MAILTO="". Я не уверен, что мне это нравится. Возможно, установка MAILTO на учетную запись только для ведения журнала поможет справиться с потопом. Другой вариант — хорошо изучить свои procmail(1) правила, чтобы полностью запихнуть их в другой почтовый ящик.

Умение управлять mutt color или score поможет вам обнаружить зерна среди плевел. (color index red black ERROR или подобные команды могут помочь вам быстрее обнаружить проблемы.)