Різниця між використанням crontab та /etc/cron.hourly,daily, щотижня

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

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

Тож мені здається, що сценарій виконується в іншому користувальницькому середовищі при запуску з cron.hourly, ніж при запуску через root crontab. Хтось може пояснити різницю?

ОНОВЛЕННЯ: Я повинен був згадати про свій дистрибутив, я використовую анакрон на CentOS 5.1.

ОНОВЛЕННЯ 2: Дякую за запропоновані пропозиції; Я думаю, що це перетворюється на більше питання про підрив. Я завжди намагаюся інкапсулювати своє середовище у свої сценарії, але проблема тут полягає в тому, що я не впевнений, що це (або не вистачає) в середовищі, яке змушує SVN просити прийняти сертифікат SSL, коли я запускаю сценарій з cron.hourly. Я здогадуюсь, що це щось пов'язане з тим, як виконується сценарій запуску частин.

Ви хочете скористатися параметром '--config-dir', щоб повідомити, де знайти прийнятий cert (наприклад, ~ / .subversion за замовчуванням).

З цього приводу я майже впевнений, що вам краще буде зателефонувати svnsync із скрипта гачок / пост-фіксації, як це запропоновано в інших місцях . Тоді ваше дзеркало завжди синхронізоване, а не синхронізовано з тим, де був ваш господар годину тому.

У системі 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 це все працює як кореневий рахунок.

Коли я пишу сценарії 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, людина 5 crontab каже:

Демон cron (8) автоматично встановлюється декількома змінними середовища. SHELL встановлюється в / bin / sh, а LOGNAME та HOME встановлюються з / etc / passwd лінії власника crontab.

Отже, якщо ви не вказали інше, crontab root буде використовувати / root для HOME. Але в / etc / crontab (де /etc/cron.hourly ведеться з, через run-parts), HOME встановлюється на / (і SHELL в / bin / bash замість / bin / sh).

Я не знаю про svnsync, але в підривному режимі використовується ˜ / .subversion / каталог, так що це може залежати від ДОМАШНОГО.

У моїй системі 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, якщо ви хочете створити пакет зі своїми речами.