Как делегировать в crontab использование другого файла в качестве crontab? он же Crontab в SVN/CVS?

Может быть, есть другое решение этого. Я создал веб-приложение, которое требует 5-10 cron для его обслуживания и различных интервалов. Я хочу зарегистрировать crontab в системе управления версиями, чтобы его можно было легко развернуть на других серверах.

Я хотел бы иметь возможность поместить строку в файл /etc/crontab, которая сообщит ему, чтобы он заглянул в файл /myapp/app.crontab и обрабатывал все строки в этом файле как записи crontab... т.е.:

0 1 * * *    root   /bin/sh /do/something.sh

Почему бы просто не проверить /etc/crontab? Потому что при развертывании с сервера на сервер некоторые серверы могут иметь разные записи в своих crontab, с которыми я не хочу вмешиваться.

Любые идеи? Что другие люди делают для хранения кучи записей crontab в rev ctrl?
Спасибо.


bash cron version-control crontab
person timh    schedule 05.02.2009    source источник

Ответы (4)


arrow_upward
4
arrow_downward

Поместите файл crontab в /etc/cron.d/ — либо как извлеченный файл, либо символическую ссылку на извлеченный файл.

person Anders Westrup    schedule 05.02.2009
comment
если вы делаете символическую ссылку, вы должны быть уверены, что у целевого файла есть правильные разрешения, и изменения файла могут быть не замечены cron. askubuntu.com/ вопросы/54857/ - person Collin Anderson; 17.06.2013
comment
@CollinAnderson, как мне убедиться, что у целевого файла есть правильные разрешения и что изменения в файле замечены? - person CMCDragonkai; 10.01.2014

arrow_upward
1
arrow_downward

Мы по-разному подходим к этой проблеме в проекте, над которым я работаю.

У нас есть Perl-скрипт с именем crontab.pl, который все серверы вызывают в своих crontab. Такой подход означает, что crontab никогда не придется изменять при последовательном развертывании приложения, а сценарий crontab.pl может счастливо жить в системе управления версиями вместе с остальными исходными файлами приложения.

Мы можем указать разные временные интервалы для этого скрипта с параметром командной строки. Кронтаб выглядит так:

*/5 * * * * /usr/local/apache/crontab.pl 5    > /var/log/crontab.log 2>&1 # 5 minute interval
1   * * * * /usr/local/apache/crontab.pl 60   > /var/log/crontab.log 2>&1 # 1 hour interval
1   1 * * * /usr/local/apache/crontab.pl 3600 > /var/log/crontab.log 2>&1 # 1 day interval

Тогда это просто вопрос чтения этого временного интервала командной строки и запуска задач, необходимых для данного интервала.

person cowgod    schedule 26.02.2009

arrow_upward
0
arrow_downward

Просто добавьте одну (или несколько) записей в crontab, и пусть эта запись будет сценарием с контролируемой версией, который вызывает другие:

0 * * * * /path/to/app/hourly.sh 0 0 * * * /path/to/app/daily.sh 0 1 * * 5 /path/to/app/weekly.sh

hourly.sh затем будет называть все, что нужно делать, hour, daily.sh — тогда все, что нужно делать ежедневно, и т. д.

Я обнаружил, что при управлении большим количеством заданий cron для одного приложения лучше всего не держать все задания в crontab свободно, потому что это побуждает вас игнорировать зависимости между ними, т. Е. Одно задание, которое выполняется в 14 минут. час зависит от задачи, которая выполняется через 12 минут после часа, следующего за часом, но время от времени эта задача занимает 2,1 минуты, а другой сценарий дает сбой, давая вам Heisenbug.

Другой подход заключается в написании собственного демона для управления этими задачами.

person skiphoppy    schedule 10.02.2009

arrow_upward
0
arrow_downward

Я делаю это так: помещаю свой файл crontab в систему управления версиями, а затем в своем сценарии развертывания я заменяю файл crontab тем, что развертывается.

Вы можете сделать это следующим образом:

crontab filename

Или для конкретного пользователя (для этого должны быть права суперпользователя):

crontab -u my_web_user filename

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

person Luke Francl    schedule 26.02.2009