Насколько я могу судить по документациисистемд, Wants=и WantedBy=выполняют ту же функцию, за исключением того, что первая помещается в зависимый файл модуля и наоборот. (Это, и WantedBy=создает unit.type.wantsкаталог и заполняет его символическими ссылками.)
ОтDigitalOcean: Понимание системных модулей и файлов модулей:
Директива
WantedBy=... позволяет вам указать отношение зависимости аналогично директивеWants=в[Unit]разделе. Разница в том, что эта директива включена во вспомогательный блок, позволяя основному перечисленному блоку оставаться относительно чистым.
Действительно ли речь идет только о поддержании файла unit "чистым"? Какова наилучшая практика использования этих двух директив? То есть, если service alpha "хочет" service beta, когда мне следует использовать Wants=beta.servicein alpha.service, а когда предпочесть WantedBy=alpha.servicein beta.service?
решение1
Функционально
Wantsнаходится в Unitразделе и WantedByнаходится в Install.
Процесс init вообще systemdне обрабатывает/не использует раздел. Вместо этого необходимо создать символическую ссылку в . Обычно это делает утилита , которая читает раздел.Installmulti-user.target.wantssystemctlInstall
В итоге,WantedByвлияет на systemctl enable/ systemctl disable.
Логически
Подумайте, какие из служб должны «знать» или «осведомляться» о других. Например, распространенное использование WantedBy:
[Install]
WantedBy=multi-user.target
Альтернативно, это может быть в multi-user.target:
[Unit]
Wants=nginx.service
Но этот второй способ не имеет смысла. Логично, что nginx.service знает о системном multi-user.target, а не наоборот.
Так что в вашем примере, если автор альфы знает о бете, то альфа Wants— бэта. Если автор беты знает об альфе, то бета — это WantedByальф.
Чтобы помочь вам принять решение, вы можете рассмотреть, какую службу можно установить (например, из менеджера пакетов) без наличия другой.
Конфигурационные каталоги
В качестве еще одного инструмента в вашем арсенале знайте, что файлы systemd также можно расширить с помощью каталогов конфигурации: /etc/systemd/system/myservice.service.d/extension.conf
Это позволяет добавлять зависимости, когда ни одна из служб изначально не создана для того, чтобы знать о другой. Я часто использую это с монтированиями, где (например) ни nginx, ни монтирование не нуждаются в явном знании друг друга, но я как системный администратор понимаю зависимость. Поэтому я создаю nginx.service.d/mymount.confс помощью Wants=mnt-my.mount.
решение2
Они функционально не идентичны. Wants=Настройка (и файлы символических ссылок) — это зависимость. Настройка WantedBy=управляет созданием/уничтожением такой зависимости при включении/отключении службы.
Так что нетлучшийпрактика. Естьправильныйпрактика. Только один из двух имеет правильную функциональность для любой данной ситуации. Либо один из них намеревается иметь постоянную зависимость, которая всегда существует, либо другой намеревается иметь временную зависимость, которая может быть включена и выключена с помощью enable/ disable.