Лучшие практики для поддержки 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' до моего поста.: P

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

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

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

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

Answer 2

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

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

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

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

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

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

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