Зачем писать в /etc/crontab, когда можно в /etc/cron.d/<anyfilename>

Calculate Русский
1

Собственно вопрос в заголовке

Зачем шаблонами править файл /etc/crontab, когда правилом хорошего тона является добавлять свои конфиги для cron-а в директорию /etc/cron.d/ в файл с “говорящим названием”?

PS
Кстати, как я понял, в /etc/crontab прописывается рандомная минута запуска этого скрипта.
Но, в таком случае, на каждой машине конфиг будет отличаться от других, что не очень правильно с точки зрения переносимости и масштабирования.

Может проще было бы прописать в него скрипт запускающий обновление в произвольную (определяемую один раз при включении компа) минуту?
К примеру в такой:

#!/bin/sh

[[ $(stat -c%y /proc/1| sed -e 's/\..*$//' -nre 's/.*:.*:([0-9]+)/\1/p') == $(date '+%M') ]] || exit 0
[ $(cut -d. -f1 < /proc/uptime) -gt 300 ] || exit 0

/usr/bin/nice -n19 /usr/sbin/cl-update -p --wait-another-update off &>/dev/null

Тут проверяется соответствие текущей минуты с секундой модификации директории /proc/1 (по сути - секундой передачи управления от ядра /sbin/init команде. Достаточно рандомный параметр).

Вторая проверка нужна, чтоб обновление не запускалось в течение первых 5 минут работы компьютера, поскольку это, в случае “удачного совпадения”, может отрицательно сказаться на скорости загрузки @
@
В этом случае конфиг cron-а запускающий поиск обновлений будет во-первых принадлежать только пакету sys-apps/calculate-update, и с обновлением/удалением (мало ли что пользователь захочет изменить) и/или этого пакета, и/или vixie-cron, все будет проходить гладко @
@
Так же, файл /etc/cron.d/calculate-update (или как вы его назовете), как и скрипт на три строки, приведенный выше, можно будет устанавливать прямо из ebuild-а пакета sys-apps/calculate-update. что, наверно, гораздо правильнее, чем лезть в конфиг шаблонами, да и просто надежнее @
@
И наконец - пользователи, захотевшие отказаться от этого способа обновления, смогут легко это сделать, создав шаблон, удаляющий этот файл.

2

Михаил Гагауз wrote:

Собственно вопрос в заголовке

Зачем шаблонами править файл /etc/crontab, когда правилом хорошего тона является добавлять свои конфиги для cron-а в директорию /etc/cron.d/ в файл с “говорящим названием”?

Поддерживаю вопрос, я тоже однажды его уже задавал. У меня уже был результат действий ваших утилит, когда, после eix-sync и обновления world, etс-update предложил заменить отредактированный мною на предмет перенаправления выхлопа cl-update в /dev/null crontab файлом нулевой длины. Хорошо что я на автомате не среагировал. Во второй раз, после eix-sync и обновления, etc-update предложил уже корректную замену моего творчества вашим исправленным вариантом задания. Поскольку это было разовое событие я не стал поднимать шума. IMHO во избежание подобных труднопредсказуемых “side effects” лучше следовать стандартным практиками и решениям.

Меня коробит когда скрипты лезет напрямую в crontab, это неправильно. Лично я, ортодокс и консерватор, приучен вносить изменения в crontab утилитой crontab, специально для этого предназначенной.

Мне кажется Михаил предлагает отличный и соответствующий стандартам вариант.

3

Кстати, как я понял, в /etc/crontab прописывается рандомная минута запуска этого скрипта.

Всё правильно, именно по этой причине вызов здесь, а не в cron.d.

Но, в таком случае, на каждой машине конфиг будет отличаться от других, что не очень правильно с точки зрения переносимости и масштабирования.

В чём же теряется переносимость и масштабирование?

4

Александр, мне кажется Михаил предложил способ как и стандарты соблюсти так и рандомности добиться. Или модифицируйте crontab вызывая утилиту crontab пожалуйста. Мне система один раз уже пыталась обнулить crontab, я не стал вникать почему, но это было бы невозможно используй вы стандартные механизмы его модификации.

5

Каждую минуту что ли скрипт запускать?

6

Каждую минуту что ли скрипт запускать?

почему нет? накладные расходы минимальные. В логи ничего не мусорит. Можно добавить сколько угодно дополнительных проверок.

Всё правильно, именно по этой причине вызов здесь, а не в cron.d.

Да даже если оставить так как есть - почему шаблонами не создавать /etc/cron.d/calculate-update?
Зачем лезть файл ни как не связанный с calculate-утилитами?

7

Но, в таком случае, на каждой машине конфиг будет отличаться от других, что не очень правильно с точки зрения переносимости и масштабирования.

Что имелось ввиду? Есть много конфигов, которые в установленной системе отличаются от таких же на другом ПК.