Блог

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

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

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

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

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

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

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

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

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

Не полный ответ, но дополнительные ресурсы, которые были полезны: 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, я бы хотел создать ярлык редактирования, который автоматически фиксируется в любой системе управления версиями, которую я использую.

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

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

Перед вами титаническая задача, желаю удачи. 🙂

Я бы посоветовал найти все задачи, которые выполняются ежедневно, и поместить их в их собственные сценарии в /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 или аналогичные команды могут помочь вам быстрее выявлять проблемы.)