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

Question

Я унаследовал обширный crontab, который мне нужно поддерживать и обновлять. У меня нет большого опыта работы с ним или написания сценариев bash (я думаю, что я достаточно хорошо разбираюсь в основах), и я хочу сделать хорошую работу. Краткий запрос: любые рекомендации по "рефакторингу" грязного crontab и набора bash-скриптов

Длинная просьба: я столкнулся с рядом проблем, но так много людей используют файлы cron и т. Д., Что я чувствую, что мне не хватает большого хранилища информации, лучших практик и инструментов - или это просто стилистическое различие для этого вид программирования? (Мой уклон: зачем делать что-то вручную, если я могу использовать инструмент, чтобы делать это быстрее, стабильнее и эффективнее?).

Примеры проблем на данный момент:

1. Из-за внешнего события crontab не работал в течение нескольких дней. Вместе с кем-то мы вручную просмотрели список, пытаясь выяснить, что не запустилось, что нам нужно было перезапустить, и какие скрипты нам нужно было отредактировать и запустить с более ранними датами и т. Д. Что я не могу найти:

   • В сети есть много (немного бессмысленных) "генераторов крон". Где обратное? Что-то, что я могу вставить в длинный crontab, две даты, и дать ли ему вывод, какие процессы должны были быть запущены, когда, или просто сколько раз всего? Это похоже на мои скудные возможности написания сценариев, так не должно ли оно уже существовать?;)
   • В качестве альтернативы, если мне когда-либо придется делать это снова, есть ли какой-нибудь способ вызова bashscript, чтобы любые экземпляры date() были предварительно установлены на более раннее время, а не меняли каждый вызов даты в скрипте? (например, для всех пропущенных отчетов и счетов-фактур)

2. Оказывается, конкретный отчет не готовился в течение двух лет. Это было просто запрошено снова, и вот, это было в crontab! В скрипте bash только что были неверные ссылки на соответствующие файлы. Что я не могу найти: какая-то проверка пути для файлов bash? Как проверка ссылок на веб-сайт. Да, в конце концов, я все это рассмотрю вручную, но это покажет некоторые, по крайней мере, некоторые проблемные области.

3. Иногда кажется, что между зависимыми процессами был слишком длинный или короткий промежуток, поэтому обновления происходили после того, как первый был запущен, или первый не завершил работу до того, как был вызван второй. Я видел несколько возможных вариантов для этого (например, Anacron работает в последовательном порядке), но что бы вы порекомендовали?

4. Существует также большое количество по сути бессмысленных электронных писем, сгенерированных из crontab (скрипты выдают ошибки, но работают "правильно", в большинстве случаев дают сбой, либо просто печатают несущественные скрипты). Я буду вручную проходить через сценарии и пытаться заставить их предоставлять более полезные данные, или "тихо преуспеть", но знаете - какие-то рекомендации?

Если мое понимание или расположение вопроса запутано, то я прошу прощения, но эй - тогда вы видите мою проблему! Мне нужно перейти от новичка к знанию того, что нужно сделать, чтобы понять это правильно, и не облажаться с сенсорной системой дальше. Спасибо!

Answer 1

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

Я медленно прохожу это и пытаюсь реализовать каждый из пунктов. Я не думал, что Google 'лучшие практики 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/

Answer 2

Геркулесова задача впереди вас, удачи.:)

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

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

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

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

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

Получать хорошо в muttcolor или же score элементы управления могут помочь вам найти пшеницу среди мякины. (color index red black ERROR или аналогичные команды могут помочь вам быстрее определить проблемы.)