Назад | Перейти на главную страницу

Эффективное управление crontab

Мой crontab выглядит примерно так:

1 * * * * /var/www/cron/site1.sh > /dev/null 2>&1

0 * * * * /var/www/cron/site2.sh > /dev/null 2>&1

3 * * * * /var/www/cron/site3.sh > /dev/null 2>&1

Это отлично работает и позволяет мне разместить все неприятные маленькие вызовы скриптов в одном месте, вместо того, чтобы усложнять чтение crontab, чем оно есть.

Но это массово терпит неудачу, когда site2.sh требуется, чтобы один сценарий запускался один раз в день, другой - раз в неделю, а третий - каждые 5 минут. И, конечно, становится хуже, поскольку новые скрипты добавляются с разным временем.

Есть ли способ лучше?

РЕДАКТИРОВАТЬ

Под «лучше» я подразумеваю сделать его более управляемым, иметь большой crontab не под силу, но и скрипты тоже не везде.

Не обязательно графический интерфейс.

Сделать crontab более управляемым, о чем я определенно мечтал много раз. Однако, когда дело доходит до этого, если вам нужно запланировать запуск 20 сценариев - ну, вам нужно запланировать запуск 20 сценариев.

Основная проблема, по крайней мере для меня, всегда заключалась в создании новой записи в /etc/crontab (или в пользовательском crontab -e). Особенно, когда эти новые записи настроены на запуск одновременно с существующей записью (или даже список записей).

Скажем, например, вам нужно 5 разных скриптов для ежечасного выполнения каждый час. Вы мог создайте для этого 5 разных записей в crontab - или - вы можете воспользоваться run-parts. run-parts позволяет указать запись crontab, как и любую другую запись, но «команда» на самом деле является каталогом. Когда пришло время выполнить команду, она выполнит каждый сценарий в заданном каталоге.

Вот список, который является общим для систем Linux:

01 * * * * root run-parts /etc/cron.hourly
02 4 * * * root run-parts /etc/cron.daily
22 4 * * 0 root run-parts /etc/cron.weekly
42 4 1 * * root run-parts /etc/cron.monthly

В первой строке /etc/cron.hourly заявляет, что каждый час в 1 минуту после часа (01 * * * *), все скрипты, расположенные в /etc/cron.hourly каталог будет выполнен. Та же концепция применяется и к другим линиям. Вы также не ограничены этим временем и каталогами - вы можете полностью настроить их в соответствии со своими потребностями в качестве стандартной записи crontab.

За исключением сценариев пакетной обработки по каталогам с run-parts, вы можете сделать вещи более управляемыми, разделив их по «пользователям» и поместив в crontab каждого пользователя через crontab -u username -e. Скажем, например, у вас есть несколько скриптов, относящихся к отчетам, вы можете создать пользователя «reportRunner» и назначить ему все связанные с отчетами crons. Поступая так, вы легко разделите списки и сможете легко управлять различными категориями скриптов / расписаний (на мой взгляд). Это не сделает общий список крон короче, но поможет сделать любой заданный список короче (и разбитым по категориям).

Я был участником некоторых довольно ужасных crontab, и от них никуда не деться. Однако я видел несколько хороших основных правил:

  1. Создать структуру
  2. Группируйте скрипты по сайту / названию / функции
  3. Аннотируйте все - так другие смогут увидеть, что происходит.
  4. Сгруппируйте кроны по сайтам (если их много), например. /var/www/site/cron/

----- 8 <-----

#### Site A ####

  #--- tasks ---#

    # cleanup sessions (ev. 20mins)
      */20 * * * * /var/www/cron/cleanup.script > /dev/null 2>&1

    # Garbage collection (ev. 24 hrs @ 0000)
      0 0 * * * /var/www/cron/gcoll.script > /dev/null 2>&1

    # De-dupe id's from x table (ev. 18 mins)
      */18 * * * * /var/www/cron/dedupe.script > /dev/null 2>&1


  #--- Reporting ---#

    # Generate mod reports (ev. 24 hrs @ 0400)
      0 4 * * * /var/www/cron/daily_report.script > /dev/null 2>&1

#### /Site A ####