Как правильно заменить rc.local в systemd вместо повторного создания rc.local

25

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

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

printf '#!/bin/bash \n\nexit 0' >/etc/rc.local 
chmod +x /etc/rc.local

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

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

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

Ответы:

17

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

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

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

# /etc/systemd/system/my-startup.service
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/local/libexec/my-startup-script

[Install]
WantedBy=multi-user.target

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

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

  2. Если ваш скрипт имеет зависимость от любого другого сервиса, в том числе 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будут показаны как «активные» после их завершения, и что вы не запустите демон.

sourcejedi
источник
Ну, есть какое-то "локальное" место для создания сервисов или фрагментов, или чего-то еще - или я могу верить, что это локально и не должно быть изменено? если я разработаю свои собственные демоны? Потому что я не хочу изменять оригинальность системы, поэтому, когда я устанавливаю некоторые apt-get, я не хочу видеть мою систему в огне из-за замененного скрипта или чего-то подобного, например. Я просто хочу верить, что демон будет запущен только один раз, без каких-либо дополнительных сумасшедших вещей, которых я боюсь ... например, попытка перезапустить его как бесконечный, если он сломан, и т. Д.
Лучано Андресс Мартини
1
@LucianoAndressMartini Если вы спрашиваете, как правильно запустить демон, вы должны определить для него отдельный сервис. Это может быть собственный системный .serviceблок, или если вы действительно хотите написать скрипт инициализации LSB, вы можете сделать это вместо этого. Я не хотел рекомендовать помещать несколько демонов rc-local.serviceили эквивалентные, я думаю, что это, вероятно, работает, но гораздо приятнее, если вы можете перезапустить отдельный демон, systemctl restart my-daemonкак и все остальное. Предполагается, что вы положите свои местные услуги /etc/systemd/system.
Sourcejedi
1
@LucianoAndressMartini вы должны избегать использования того же имени, что и любой другой сервис - как в sysvinit. В подобных ситуациях я иногда начинал свои имена с local-...
sourcejedi
1
Спасибо!!! Сохранено через полдня. Эти детали были критически важны для меня: Type = oneshot, RemainAfterExit = yes, Wants = network-online.target, After = network-online.target. Просто разверните сборку apache и настройте статический IP на 192.168.1.80, чтобы маршрутизатор мог направлять туда трафик. Должно быть тривиально. Это раздражает в Debian9. Практически никаких онлайн-советов, кроме «apt-get apache», «systemctl start apache» или инструкций с init.d, ни один из которых не подходит для Apache, созданного из исходного кода под Debian9.
МайклсонБритт
1
@MichaelsonBritt Лучше всего не запускать долго работающие программы или демоны из rc.local. Я использовал Type=oneshot... это формализует это ... ты не запустишь демона. Если вы хотите получить информацию о запуске демона, задайте новый вопрос.
Sourcejedi
15

Забудь о rc.local.

Как я уже говорил о CentOS 7 и Debian 8 и Ubuntu 15 :

Вы используете операционную систему systemd + Linux. /etc/rc.localявляется механизмом двойной обратной совместимости в systemd, поскольку он является механизмом обратной совместимости для механизма, который сам по себе являлся механизмом совместимости в клоне van Smoorenburg System 5 rc.

Использование /etc/rc.localможет пойти ужасно неправильно. Люди были удивлены тем фактом, что systemd работает не rc.localсовсем так, в том же месте в начальной загрузке, как они привыкли. (Или ошибочно ожидать: на самом деле он не работал последним в старой системе, как все еще указывает руководство OpenBSD.) Другие были удивлены тем фактом, что они настроены на rc.localожидание старых способов ведения дел. затем полностью отменить подобные новых udevправила, NetworkManager, systemd-logind, systemd-resolvedили различный «Кит» с.

Как проиллюстрировано " Почему` init 0` приводит к "Избыточным аргументам" при установке Arch? "», Некоторые операционные системы уже предоставляют systemd без функций обратной совместимости, таких как systemd-rc-local-generatorгенератор . В то время как Debian по-прежнему сохраняет функции обратной совместимости , Arch Linux собирает systemd с их выключенными . Так что в Arch и операционных системах, подобных ей, ожидается /etc/rc.local полное игнорирование .

Забудь о rc.local. Это не путь. У вас есть операционная система systemd + Linux. Поэтому создайте правильный системный сервисный модуль и не начинайте с того момента, когда нет двух уровней обратной совместимости. (В Ubuntu и Fedora, это три раза удалены, фургон Smoorenburg System 5 rcклон, а затем rc.localто , а затем уже сам дважды вытеснили, более десяти лет назад, сначала выскочкой , а затем Systemd.)

Также помните первое правило для миграции на systemd .

Это даже не новая идея, специфичная для systemd. В системах van Smoorenburg rcи Upstart нужно было сделать правильный rcсценарий van Smoorenburg или файл задания Upstart, а не использовать его rc.local. Даже руководство FreeBSD отмечает, что в настоящее время rcвместо использования используется правильный сценарий Mewburn /etc/rc.local. Mewburn rcбыл представлен NetBSD 1.5 в 2000 году.

/etc/rc.localдаты со времени седьмого издания Unix и до. Он был заменен /etc/inittabи основан на уровне запуска rcв AT & T Unix System 3 (с немного отличающимся /etc/inittabв AT & T Unix System 5) в 1983 году . Даже это теперь история.

Создание собственных определений нативных служб для системы управления услугами, будь то служба расслоение для перекуса набора инструментов - х service-managerи system-control, /etc/rc.d/скрипт для Mewburn rc, служебный блок файл для Systemd, файл задания для Upstart, каталог услуг для runit / s6 / DaemonTools - или даже /etc/init.d/сценарий для ван Смуренбурга rc.

В systemd такие файлы, добавленные администратором, /etc/systemd/system/обычно добавляются (или /usr/local/lib/systemd/system/редко). С Nosh Service Manager, /var/local/sv/это обычное место для локальных пакетов услуг. Mewburn rcна FreeBSD использует /usr/local/etc/rc.d/. Файлы упакованных сервисных модулей и сервисные пакеты, если вы их делаете, все же отправляются в разные места.

дальнейшее чтение

JdeBP
источник
2
@LucianoAndressMartini Лучший вопрос - как обработать определенный фрагмент rc.local в сервисе systemd. Так что, если у вас есть определенный фрагмент (вы упомянули инструкции из документации по некоторому программному обеспечению), возможно, вместо этого разместите вопрос об этом? Существуют определенные общие правила, которые можно использовать для преобразования, но вы извлекаете из этого больше пользы, используя функции программного обеспечения, которое вы используете (например, запуск на переднем плане, не пытаясь демонизировать и т. Д.), Поэтому спрашивая о конкретном случае может быть полезным
filbranden
4
Вы должны задаться вопросом, пережил ли он амортизацию с 1983 года, может быть, что-то идет на это?
Дэн Картер
4
Этот ответ является проповедническим и фактически не может ответить на простой вопрос: «Какую банальную вещь я должен сделать вместо этого?». Он может содержать информацию и предоставлять тонны ссылок, но не отвечает цели стека обмена.
GPS
Я привожу это (конец rc.local) вместе с dns, решающим проблемы, как причины, по которым linux не развивается, а фактически становится спагетти-кодом все больше и больше, systemd стал черным ящиком для многих. Если пользователь или администратор хочет поместить что-то в rc.local и больше не может, не стоит заставлять их сначала проводить курсы systemd или что-либо еще, что вы проповедуете, чтобы достичь того же конечного результата в днях, а не в минутах. Конечно, идиоты могут делать глупости со всем, что работает хорошо и с которым легко работать, это никогда не является веским аргументом в пользу завершения.
Юлий
2

Резюме https://www.linuxbabe.com/linux-server/how-to-enable-etcrc-local-with-systemd

Создайте /etc/systemd/system/rc-local.service:

# /etc/systemd/system/rc-local.service
[Unit]
 Description=/etc/rc.local Compatibility
 ConditionPathExists=/etc/rc.local

[Service]
 Type=forking
 ExecStart=/etc/rc.local start
 TimeoutSec=0
 StandardOutput=tty
 RemainAfterExit=yes
 SysVStartPriority=99

[Install]
 WantedBy=multi-user.target

Затем:

sudo touch /etc/rc.local
sudo chmod +x /etc/rc.local
sudo systemctl enable rc-local

Проверить с:

sudo systemctl start rc-local.service
sudo systemctl status rc-local.service
Оле Танге
источник
Используется systemd StandardOutput=journal+console(консоль эквивалентна tty в вашем примере), что кажется гораздо более полезным для устранения неполадок. Также поддержка SysVStartPriority=была удалена в какой-то момент. Может быть, вы могли бы прокомментировать, насколько это важно SysVStartPriority=, или удалить его. Кроме того, это достойный ответ.
Sourcejedi