Мой 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, и от них никуда не деться. Однако я видел несколько хороших основных правил:
/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 ####