Надежное отключение определенного скрипта cron.{Почасовой, ежедневный, еженедельный}
В различных системах, которые я администрирую, есть сценарии cron, которые запускаются через обычно используемые /etc/cron.{hourly,daily,weekly} раскладка. То, что я хочу знать, есть ли какие-либо общие функции "отключить этот скрипт".
Очевидно, что простое удаление чего-либо из заданного каталога отключит его, но я ищу более постоянное решение. Удаление /etc/cron.daily/slocate будет работать, чтобы отключить ночные updatedb на моей домашней машине (где я никогда не использую slocate), но в следующий раз, когда я обновлю пакет slocate, я почти уверен, что он появится снова.
Два дистрибутива, которые меня больше всего интересуют, это Gentoo и OpenSUSE, но я надеюсь, что есть широко реализованный механизм. Оба дистрибутива, так как я их использую, используют vixie-cron (не уверен, что это имеет значение).
8 ответов
Ты должен быть способен chmod -x scriptname отключить скрипт, но оставить файл на месте.
Run -parts не выполняет задания, в имени которых есть точка, поэтому
mv /etc/cron.d/job /etc/cron.d/job.disabled
сделает свое дело.
Обычно cron.daily вызывается через /etc/crontab через линию, например, например
run-parts --report /etc/cron.daily
man run-parts дает вам варианты.
run-parts --test /etc/cron.daily показывает, какие задания выполняются без их запуска.
Я предпочитаю создать подпапку "Disabled" и перенести туда свою работу.
В любом случае, если вы обновите пакет, вполне вероятно, что задание снова станет на свое место или что восстановленные биты "x" будут восстановлены.
/Etc/cron.daily et. и др. скрипты запускаются скриптом, называемым run-parts. Этот сценарий меняется. Например, упомянутый выше ключ --test отсутствует на компьютере, которым я сейчас пользуюсь.
Run-parts - это скрипт bash. Это обычно полезный инструмент для запуска всех сценариев в каталоге, указанном в качестве аргумента. Обычно он находится в / usr / bin / run-parts.
Это имеет путаницу логики для решения, что бежать. Этот код содержит ответ на ваш вопрос, но он также различается. Поэтому вам нужно прочитать код, чтобы быть в безопасности.
В версии, которую я смотрю, есть логика, которая при работе с каталогом проверяет наличие /jobs.deny. Если он существует, он отказывается запускать какой-либо сценарий, упомянутый в этом файле, в одиночку. Предполагая, что у вас есть эта функциональность, это потрясающе, потому что она будет продолжать работать после установки или обновления устанавливаемого пакета.
Вы можете удалить пакет slocate, если вы никогда не используете его.
Если вы используете cfengine ( https://cfengine.com/), вы можете сделать это с отключением. Вы просто пишете файл обещания для группы хостов, и он применит себя при следующем запуске cfagent. Делать это с марионеткой, шеф-поваром или чем-то еще тоже должно быть довольно просто.
Если иметь дело с RHEL и дериватами (что обеспечивает crontabs пакет), вы можете явно отключить задание, поместив его имя в jobs.deny файл.
Из справочной страницы crontabs / run-parts:
Выполнение файлов можно разрешить или запретить, создав файл jobs.allow или jobs.deny, который работает аналогично другим файлам конфигурации allow/deny. Файл должен быть создан в указанном каталоге.
Пример /etc/cron.daily/jobs.deny может содержать, например, 0logwatch, который запрещает выполнение этого скрипта.
Если вы также не хотите использовать пользовательские crontabs, просто отключите crond в вашем списке служб.
В Debian и версиях, основанных на Debian, это просто вопрос удаления символической ссылки из соответствующего файла /etc/rcX.d (для уровня запуска X).
Я не знаю, как вы обрабатываете сервисы в SUSE или Gentoo.