Надежное отключение определенного скрипта cron. {Почасовой, ежедневный, еженедельный}

25

В различных системах, которые я администрирую, есть сценарии cron, которые запускаются через обычно используемый /etc/cron.{hourly,daily,weekly}макет. То, что я хочу знать, есть ли какие-либо общие функции «отключить этот скрипт».

Очевидно, что простое удаление чего-либо из заданного каталога отключит его, но я ищу более постоянное решение. Удаление /etc/cron.daily/slocateбудет работать, чтобы отключить ночной режим updatedbна моем домашнем компьютере (где я никогда не использую slocate), но в следующий раз, когда я обновлю пакет slocate, я почти уверен, что он появится снова.

Два дистрибутива, которые меня больше всего интересуют, это Gentoo и OpenSUSE, но я надеюсь, что есть широко реализованный механизм. Оба дистрибутива, так как я их использую, используют vixie-cron (не уверен, что это важно)

cron cron.daily

— benizi
источник

45

Вы должны иметь возможность chmod -x scriptnameотключить скрипт, но оставить файл на месте.

— Приостановлено до дальнейшего уведомления.
источник

5

Это может или не может быть отменено системой управления пакетами. Вы можете сделать это более надежным, сделав chattr +i scriptnameпосле chmod.

— mc0e

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

— Джонатан Я.

2

@JonathanY .: Это то, что lsattrдля - удалить страшно (в нем перечислены атрибуты файла).

— Приостановлено до дальнейшего уведомления.

1

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

— Джонатан Я.

@JonathanY. Итак, теперь вы знаете. :-) В любом случае, я думаю, что «страшный» бит в этой связанной теме относится к ошибке pacman, а не к самому chattr

— mc0e

9

run-parts не выполняет задания, в имени которых есть точка, поэтому

mv /etc/cron.d/job /etc/cron.d/job.disabled

сделает свое дело.

— chrisv
источник

1

К сожалению, при обновлении программы возникнет та же проблема - она проверит, существует ли задание cron, и, поскольку оно не существует по своему первоначальному имени, оно будет воссоздано.

— Дженни Ди говорит восстановить Монику

2

Возвращение при обновлении программы является побочным эффектом используемого пакетного инструмента, не может быть исправлено простыми средствами и не является ошибкой Cron. Некоторые системы пакетирования удаляют и загружают предыдущие файлы, другие разрабатывают новые и старые, и запрашивают, есть ли изменения для проверки. В любом случае, обновления, которые вызывают непреднамеренное поведение, должны быть разочаровывающей, но рутинной частью администрирования Unix-систем на данном этапе. Просто слишком много пакетов движется слишком быстро, чтобы регулярно просматривать все изменения на предмет их влияния в каждой отдельной среде.

— Пилман

В Debian есть понятие перенаправления файлов - то есть вы можете эффективно переименовать файл, пока он все еще управляется менеджером пакетов. Может быть, похожий механизм существует в Gentoo и / или SUSE?

— Бас

9

Обычно cron.dailyвызывается через /etc/crontabстроку, например, например

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

man run-parts дает вам варианты.

run-parts --test /etc/cron.daily показывает, какие задания выполняются без их запуска.

Я предпочитаю создать подпапку «Disabled» и перенести туда свою работу.

В любом случае, если вы обновите пакет, вполне вероятно, что задание снова станет на свое место или что восстановленные биты «x» будут восстановлены.

— Питер
источник

1

Вы можете удалить пакет slocate, если вы никогда не используете его.

— Maxfer
источник

Это был просто пример, но все же хороший совет, спасибо. (Я думал, что что-то может зависеть от slocate, но, похоже, ничего не происходит.)

— benizi

Удалите slocate и установите вместо него mlocate. Намного лучше.

— mc0e

1

Если вы используете cfengine ( https://cfengine.com/ ), вы можете сделать это с отключением. Вы просто пишете файл обещания для группы хостов, и он применит себя при следующем запуске cfagent. Делать это с марионеткой, шеф-поваром или чем-то еще тоже должно быть довольно просто.

— natxo asenjo
источник

Интересный. Я только случайно столкнулся с инструментами управления конфигурацией. Я искал общее решение «У меня есть произвольная Unix-подобная система».

— Бенизи

1

/Etc/cron.daily et. и др. скрипты запускаются скриптом, называемым run-parts. Этот сценарий меняется. Например, упомянутый выше ключ --test отсутствует на компьютере, которым я сейчас пользуюсь.

Run-parts - это скрипт bash. Это обычно полезный инструмент для запуска всех сценариев в каталоге, указанном в качестве аргумента. Обычно он находится в / usr / bin / run-parts.

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

В версии, которую я смотрю, есть логика, которая при работе с каталогом <foo> проверяет наличие <foo> /jobs.deny. Если он существует, он отказывается запускать какой-либо сценарий, упомянутый в этом файле, в одиночку. Предполагая, что у вас есть эта функциональность, это потрясающе, потому что она будет продолжать работать после установки или обновления устанавливаемого пакета.

— Бен Хайд
источник

0

Если вы имеете дело с RHEL и производными (которые предоставляют crontabsпакет), вы можете явно отключить задание, поместив его имя в jobs.denyфайл.

Из справочной страницы crontabs / run-parts :

Выполнение файлов можно разрешить или запретить, создав файл jobs.allow или jobs.deny, который работает аналогично другим файлам конфигурации allow / deny. Файл должен быть создан в указанном каталоге.

Пример /etc/cron.daily/jobs.deny может содержать, например, 0logwatch, который запрещает выполнение этого скрипта.

— shodanshok
источник

-1

Если вы также не хотите использовать пользовательские crontabs, просто отключите crond в вашем списке служб.

В Debian и версиях, основанных на Debian, это просто вопрос удаления символической ссылки из соответствующего файла /etc/rcX.d (для уровня запуска X).

Я не знаю, как вы обрабатываете сервисы в SUSE или Gentoo.

— Jishi
источник

4

Это просто плохая идея. Отключение cron полностью отключит полезные задачи обслуживания, такие как logrotate, updatedb, возможно автоматические обновления и стандартные резервные копии.

— Тобу

Updated - это именно та задача, которую я пытаюсь отключить (обновляет базу данных для slocate). Тем не менее, да, плохой совет в целом.

— Бенизи

Ой, извини. Я неправильно прочитал ваш вопрос и подумал, что вы хотите отключить ВСЕ системные специфичные cronjobs, а не одну конкретную.

— Джиши