Куди поставити системні кронштейни?


11

Якщо мені потрібна робота cronjob, яка працює на системному рівні (тобто не специфічна для певного користувача), як ви запропонуєте мені створити її?

  1. працює crontab -eяк корінь
  2. додаючи його до /etc/crontab
  3. створення файлу, що визначає cronjob в /etc/cron.d/
  4. створення файлу, що визначає cronjob в /etc/cron.*ly/(але тільки якщо такий часовий інтервал відповідає моїм потребам)

Що мене найбільше хвилює: яке з цих рішень можливо буде перезаписане оновленням системи ?

Крім того, я здогадуюсь, що якщо робота тривала, я повинен розміщувати її в окремому файлі сценарію , наприклад, в /root/bin/. Ви згодні?


3
Ви повинні вказати, яким дистрибутивом Unix або Linux ви користуєтесь.
jlliagre

Я зараз тільки вчуся :) Я думав, що це поведінка, що не залежить від дистрогу ...
синюватий

Відповіді:


13

Не використовуйте crontab -e

Я не ставлю це crontab -eяк корінь. Це, як правило, менш очевидно для інших адміністраторів і, ймовірно, з часом загубиться. Помістивши їх, /etc/crontabви можете точно вказати час, коли ви хочете, щоб вони працювали, а також можна вказати іншого користувача.

Альтернативні місця розташування

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

Наприклад, у дистрибутиві на основі Redhat:

$ ls -dl /etc/cron*
drwxr-xr-x. 2 root root 4096 Nov 29 11:06 /etc/cron.d
drwxr-xr-x. 2 root root 4096 Nov 29 11:06 /etc/cron.daily
-rw-------. 1 root root    0 Nov 23 07:42 /etc/cron.deny
drwxr-xr-x. 2 root root 4096 Nov 29 11:03 /etc/cron.hourly
drwxr-xr-x. 2 root root 4096 Nov 29 11:06 /etc/cron.monthly
-rw-r--r--. 1 root root  457 Sep 26  2011 /etc/crontab
drwxr-xr-x. 2 root root 4096 Sep 26  2011 /etc/cron.weekly

Я часто розміщую крони системного рівня, які я хочу запустити в певний час /etc/cron.dзамість /etc/crontab, особливо якщо це складніші сценарії.

Я вважаю за краще використовувати каталоги в, /etc/cron*тому що вони набагато очевидніше місце, де інші системні адміністратори будуть знати, і файлами тут можна керувати за допомогою встановлення пакетів, таких як rpmта / або apt.

Захист записів

Будь-який із каталогів, про які я згадував, призначений для розміщення сценаріїв, які не будуть зруйновані менеджером пакунків. Якщо ви стурбовані захистом запису на кронтаб, я б точно не вкладав його у /etc/crontabфайл, а замість цього ставлю його як належний сценарій в одному з /etc/cron*каталогів.


1

Я вибрав би №4. Це дозволяє налаштуванням системи вибирати, коли виконувати роботу, і зазвичай вони роблять хорошу роботу "запускати, коли не зайнятий". Зміна системного планувальника Cron також автоматично впливає на час виконання сценарію.

Нижня сторона полягає в тому, що ви не маєте прямого контролю над її запуском. Якщо вам потрібен прямий контроль, тоді використовуйте №1.

Найменше ймовірність перезаписати оновлення системи. Хоча 3 і 4 мають бути досить безпечними. все залежить від способу оновлення. Ваш дистрибутив може оновлюватись, як хоче, але лише 2, як правило, ризикує перезаписати.

Нарешті, я ставлю сценарії в / usr / local / bin. Це "нормальне" місце, в яке я розміщую системні речі, якими не керує менеджер пакунків дистрибутива. / root / bin також прийнятний, якщо він буде запускатися тільки root. Однак це все переважно смак.


0

Будь-яке з перерахованого вище спрацює, і жодне з перерахованих вище не повинно бути перезаписане оновленнями. Фактичний вибір зводиться до думки - будь-які троє різних людей найчастіше матимуть як мінімум дві, якщо не три різні відповіді.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.