Centos rc local не работает

Обновлено: 07.07.2024

Я не могу найти правильный способ выполнения некоторых локальных сценариев (или очень локальных команд) в systemd, я уже знаю, что не должен создавать службу (в systemd модуле) для таких сценариев (или я должен?) .

Обходной путь, который я нашел, состоит в том, чтобы создать rc.local и дать ему разрешения на выполнение.

Например, если я получу устаревший сервер с настроенным вами простым rc.local, я буду знать, что вы делали, и насколько это повредит обновлению или установке чего-то нового в дистрибутиве, поскольку rc.local уважался внешним пакеты, но с другой стороны, если я устанавливаю сервер и создаю системный модуль или два или три (или даже службы sysvinit), просто для выполнения простой задачи, это может иногда сделать вашу жизнь тяжелее, и намного больше, чем это мои модули Когда-нибудь имена могут конфликтовать с именами новых сервисов, созданных при разработке дистрибутива и, возможно, установленных при обновлении, что вызовет проблемы для моих скриптов!

Я вижу еще один вопрос с просьбой о где rc.local и ответ должен был создать и дать права исполнения, я думаю , что мой вопрос на самом деле не дубликат , потому что я не хочу знать , где это - поверьте, я просто хочу чтобы принять , что она устарела , но я не могу найти правильный путь для ведения такого рода вещи, я должен действительно создать устройство только для некоторых простых , как это?

systemd «единственный выигрышный ход - не играть»; альтернативно, в зависимости от того, что вы хотите, вы можете создать системный модуль. Я бы, наверное, сейчас использовал rc.local и позаботился бы об этом, когда он уйдет. То есть вы думаете, что официальный способ - создать подразделение, подобное сервису? Пожалуйста, напишите в качестве ответа, как это сделать. Когда я попробовал Ubuntu, я создал модуль для постоянного кэширования ssh-агента на моем рабочем столе, пока я не перезагружался, а другой для чего-то еще, что я не помню; Вы также можете создать один, указывающий на /etc/rc.local, но, похоже, система делает это для себя на данный момент . Я бы на данный момент rc.local, и если будет прекращено, создать один, указывающий на подделку /etc/rc.local тогда. Это может нарушить документацию, как если бы в какой-то книге говорилось, что вы должны поместить что-то в /etc/rc.local, и вы пытаетесь обновить этот документ, например, если rc.local должен быть помечен как исполняемый, когда он полностью устарел документация не работает, но если вы говорите, что должны создать модуль, указывающий на /etc/rc.local, это нарушит документацию, поскольку systemd конфликтует с вашим модулем. Я полагаю, если вы правы, они, вероятно, не решили, является ли это устаревшим или нет, потому что у них все еще нет замены . когда они решат, что вся документация будет снова сломана. Какой вид сценария вам нужно выполнить? Systemd имеет много типов юнитов. «Сервис» - это только один из многих типов единиц . Например, монтирование юнитов, автомонтирование юнитов, таймеров, целевых юнитов Может ли один из них решить вашу проблему?

Как указано в другом месте, он становится умеренно нечистым для использования rc-local.service под systemd .

  1. Теоретически возможно, что ваш дистрибутив не включит его. (Я думаю, что это не распространено, например, потому что отключение той же опции сборки также удаляет poweroff / reboot команды, которые используют многие люди).
  2. Семантика не совсем понятна. Systemd определяет rc-local.service один путь, но Debian предоставляет раскрывающийся файл, который изменяет по крайней мере один важный параметр.

rc-local.service часто может работать хорошо. Если вы беспокоитесь о вышесказанном, все, что вам нужно сделать, это сделать свою собственную копию! Вот волшебство:

Я не думаю, что вам нужно понимать каждую деталь [*], но здесь нужно знать две вещи.

Вы должны включить это с systemctl enable my-startup.service .

Если ваш скрипт имеет зависимость от любого другого сервиса, в том числе network-online.target , вы должны объявить его. Например, добавить [Unit] раздел с линиями Wants=network-online.target и After=network-online.target .

Вам не нужно беспокоиться о зависимости от сервисов «ранней загрузки», в частности, сервисов, которые уже были заказаны ранее basic.target . Такие сервисы my-startup.service автоматически заказываются после basic.target , если они не установлены DefaultDependencies=no .

Если вы не уверены, является ли одна из ваших зависимостей службой «ранней загрузки», один из подходов заключается в перечислении служб, которые были упорядочены ранее basic.target , путем их запуска systemctl list-dependencies --after basic.target . (Обратите внимание, это --after не так --before ).

Есть некоторые соображения, которые, я думаю, также применимы к pre-systemd rc.local :

  1. Вы должны убедиться, что ваши команды не конфликтуют с другой программой, которая пытается контролировать то же самое.
  2. Лучше всего не запускать долго работающие программы, также известные как демоны rc.local .

[*] Я использовал Type=oneshot +, RemainAfterExit=yes потому что это имеет больше смысла для большинства одноразовых сценариев. Он формализует, что вы запустите ряд команд, которые my-startup будут показаны как «активные» после их завершения, и что вы не запустите демон.

Читайте также: