Удаление зависимостей юнитов systemd

Насколько мне известно, существует относительно удобный способ частичного переопределения дистрибутивных юнитов путём включение их в свои через .include и последующего ДОБАВЛЕНИЯ параметров.

Однако, мне ещё ни разу не удалось им воспользоваться, хотя мне пришлось переопределить уже несколько юнитов.
Причина – во всех случаях мне требовалось, кроме всего прочего, ОТМЕНИТЬ некоторые зависимости этих юнитов, но мне НЕизвестны способы ОТКЛЮЧАТЬ уже имеющиеся параметры, только добавлять новые.

Кто-нибудь знает, как это можно сделать?
До сих пор я просто копировал файлы юнитов из /usr/lib/systemd/system/ в /etc/systemd/system/ и редактировал копии. Это работает, но мне не нравится перспектива в будущем заниматься ручной синхронизацией содержимого этих файлов в случае обновления.
Что-то подобное упомянуто в “man systemd.unit” сразу после таблицы спецификаторов:
If a unit file is empty (i.e. has the file size 0) or is symlinked to /dev/null its configuration will not be loaded and it appears with a load state of masked, and cannot be activated. Use this as an effective way to fully disable a unit, making it impossible to start it even manually.
То есть, таким способом можно вообще выключить любой юнит.
Спасибо за совет, но мне нужно не выключить юнит, а убрать у него некоторые лишние зависимости, чтобы запустить его раньше :)
Для изменения порядка да, только Before=, After= и Requires=. Причем Requires= будет иметь приоритет перед After=, как я понял из того же мана.
Пока только так…
Допустим, некоторые сетевые демоны являются серверами, а не клиентами, и для их запуска не требуется предварительная настройка сети, потому что они не будут сами ни к кому подключаться, а только ждать, когда подключатся к ним. Соответственно, для них них надо из After= убрать network.target

Далее, у нас есть юниты, необходимые для запуска getty, то есть логина в консоли, но они зависят в том числе от remote-fs.target . Даже если у меня есть удалённо монтируемые каталоги, в моём случае они не требуются на самом деле для логина, если конечно, /home на монтируется тоже по сети.
Юнит remote-fs.target вполне логично и ожидаемо будет готов не просто после готовности сети, но аж после завершения монтирования сетевых каталогов. Если нам не требуется для нормального логина ждать этого, то надо убрать у некоторых юнитов зависимости от remote-fs.target

Пока я не нашел, как сделать это иначе, чем скопировав файлы юнитов целиком и исправив в них нужные строчки.
При таком перфекционистском подходе, думаю, копирование юнитов единственное решение на данном этапе развития systemd. Хотя, как Вы заметили, не самое легкое при необходимости отслеживания изменений. Все таки, для большинства предлагаемая последовательность загрузки вполне приемлема.
Хочу сделать замечание относительно примера с сетевыми демонами: как раз тем сервисам, которые выступают в качестве серверов, необходимо наличие сети, т.к. биндинг портов для прослушивания подключений происходит к конкретным интерфейсам с ip адресами, которые при старте уже должны быть подняты. Например, если поднять named, а потом поднять еще один интерфейс, то named не станет слушать на этом новом интерфейсе без перезапуска демона. (Впрочем, уверен, что просто пример был приведен не совсем удачный.)
kurych
При таком перфекционистском подходе
Какой уж тут перфекционистский подход? Главным достоинством systemd объявлена возможность одновременного запуска демонов, однако идущие “из коробки” юниты этого не обеспечивают, даже хуже – если в initcripts достаточно добавить @ перед именем демона в rc.conf, чтобы не ждать его готовности, то тут надо править юниты. В результате, к примеру, если у вас включён юнит для dhcpcd, то при отключённой сети вы будете ждать, пока истечёт таймаут, и только потом сможете добраться до логина. Борьба с этим не особенно похожа на перфекционизм, не так ли?

Хочу сделать замечание относительно примера с сетевыми демонами: как раз тем сервисам, которые выступают в качестве серверов, необходимо наличие сети, т.к. биндинг портов для прослушивания подключений происходит к конкретным интерфейсам с ip адресами, которые при старте уже должны быть подняты. Например, если поднять named, а потом поднять еще один интерфейс, то named не станет слушать на этом новом интерфейсе без перезапуска демона. (Впрочем, уверен, что просто пример был приведен не совсем удачный.)
В моём случае ни один демон-сервер не биндится к интерфейсам и конкретным айпи.
Идеально будет, если этот вопрос вы зададите самому Поттерингу, например в гуглоплюсе. Он там постоянно обитает, так что шанс на ответ очень высок.
 
Зарегистрироваться или войдите чтобы оставить сообщение.