Разница между использованием crontab и /etc/cron.hourly,daily,weekly

У меня есть запланированный скрипт, который делает почасовое резервное копирование svnsync наших репозиториев Subversion. Я запускал его из записи в корневом crontab без проблем, но решил, что вместо этого я хотел бы запустить его из /etc/cron.hourly для большей наглядности (и потому, что один из наших инженеров случайно удалил crontab, потому что он подумал: "crontab -r "значит" читать crontab ;-))

Все команды svnsync в сценарии cron.hourly завершаются с ошибкой с сообщением о том, что SSL-сертификат для репозитория SVN должен быть принят (это сообщение, которое вы получаете в интерактивном режиме при первом обращении пользователя к репозиторию SVN, но как только сертификат I принял сообщение больше не приходит)

Так что мне кажется, что скрипт выполняется в другой пользовательской среде при запуске из cron.hourly, чем когда он запускается через корневой crontab. Кто-нибудь может объяснить разницу?

ОБНОВЛЕНИЕ: я должен был упомянуть мой дистрибутив, я использую анакрон на CentOS 5.1.

ОБНОВЛЕНИЕ 2: Спасибо за предложения до сих пор; Я думаю, что это превращается в вопрос Subversion. Я всегда пытаюсь инкапсулировать свою среду в свои сценарии, но проблема здесь в том, что я не уверен, что находится в (или не хватает) среде, которая заставляет SVN запрашивать сертификат SSL, когда я запускаю свой сценарий из cron.hourly. Я предполагаю, что это как-то связано с тем, как выполняется скрипт run-parts.

Вы хотите использовать опцию --config-dir, чтобы сообщить, где найти принятый сертификат (например, ~ / .subversion по умолчанию).

Тем не менее, я почти уверен, что вам лучше вместо этого вызывать svnsync из скрипта hooks / post-commit, как это предлагается в другом месте . Тогда ваше зеркало всегда синхронизировано, а не синхронизировано с тем, где ваш мастер был час назад.

В системе Debian / Ubuntu cron.daily | еженедельно | ежемесячно запускаются из основного crontab.

17 *    * * *   root    cd / && run-parts --report /etc/cron.hourly
25 6    * * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
47 6    * * 7   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
52 6    1 * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )

Также имейте в виду, что вы, вероятно, можете поместить фрагмент crontab в /etc/cron.d/

Как видите, в этой среде нет ничего особенного. По крайней мере, в Debian / Ubuntu все это запускается от имени учетной записи root.

Когда я пишу сценарии cron в самом начале сценария, я всегда устанавливаю свой PATH и другие переменные окружения, которые я буду использовать, поэтому я могу быть уверен, что он будет работать правильно в любой среде.

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

Использование сценариев /etc/cron.*(ежечасно, ежедневно, еженедельно, ежемесячно) является более понятным и простым способом (предотвращает распространенные синтаксические ошибки) настройки crontab для rootпользователя, и это выполняется с помощью run-partsзапуска сценариев или программ в каталоге. Все эти правила все еще определены в общесистемном crontab по умолчанию ( /etc/crontab), так что это одно и то же.

Когда задачи cron обрабатываются run-parts, их легче отлаживать, так как вы можете просто проверить, какие сценарии будут в точности выполняться (без их запуска):

sudo run-parts --report --test /etc/cron.daily

Моим первым диким предположением будет проверка вашей переменной HOME.

В моей системе Centos man 5 crontab говорит:

Несколько переменных окружения устанавливаются автоматически демоном cron (8). SHELL установлен в / bin / sh, а LOGNAME и HOME установлены в строке / etc / passwd владельца crontab.

Итак, если вы не указали иначе, crontab root будет использовать / root для HOME. Но в / etc / crontab (откуда запускается /etc/cron.hourly через части выполнения) HOME устанавливается на / (и SHELL на / bin / bash вместо / bin / sh).

Я не знаю о svnsync, но Subversion использует каталог ˜ / .subversion /, так что это может зависеть от HOME.

В моей системе RHEL 5.1 переменная окружения PATH установлена ​​в / etc / crontab. Все это наверху - это то, что подается в окружающую среду.

Если вы перезапустите cron, то при первом запуске (если из /etc/crontabили /var/spool/cron/$USER) он запишет это в / var / log / cron. В противном случае он просто заметит, что cron.hourly побежал

Мой crontab настроен на следующее:

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:

env > /tmp/cron.env

Затем проверьте файл, когда он появится, или измените ваш скрипт (если вы можете), чтобы правильно настроить среду, или напишите короткий скрипт-обертку, который вызовет ваш crontab.

/var/log/messages (или эквивалент вашего дистрибутива) должен рассказать вам о том, какая команда была запущена, когда и от имени какого пользователя.

Никогда не думайте, что в окружающей среде что-то есть. Всегда используйте защитный код. У вас есть целый файл, чтобы поместить туда все, что вам нужно. Используй это.

Не говоря уже о переносимости, в последний раз, когда я проверял (в Debian), было рекомендовано помещать вещи в cron.hourly (и другие), а не прямо в crontab, если вы хотите создать пакет со своими вещами.