Systemd: требует против хочет


18

Есть ли какая-либо разница между Требуется против Желаний в целевых файлах?

[Unit]
Description=Graphical Interface 
Documentation=man:systemd.special(7)
Requires=multi-user.target
Wants=display-manager.service

Благодарность


2
Видитеman systemd.unit
Heemayl

Ответы:


12

Как отметил Хеймайл в комментарии, справочная страница отвечает на ваш вопрос. Из Интернета:

Хочет =

Более слабая версия требует =. Единицы, перечисленные в этой опции, будут запущены, если единицей конфигурирования является. Однако, если перечисленные блоки не запускаются или не могут быть добавлены к транзакции, это не влияет на достоверность транзакции в целом. Это рекомендуемый способ привязки запуска одного блока к запуску другого блока.

И требует =:

Настраивает зависимости требований от других модулей. Если этот блок активируется, перечисленные здесь блоки также будут активированы. Если один из других модулей будет деактивирован или его активация не удастся, этот блок будет деактивирован. Эта опция может быть указана более одного раза, или несколько разделенных пробелами единиц могут быть указаны в одной опции, и в этом случае будут созданы зависимости требований для всех перечисленных имен. Обратите внимание, что зависимости требований не влияют на порядок запуска или остановки служб. Это должно быть настроено независимо с опциями After = или Before =. Если юнит foo.service требует юнита bar.service, настроенного с помощью Требуется =, и не настроен порядок упорядочения После = или До =, тогда оба блока будут запущены одновременно и без каких-либо задержек между ними, если активирован сервис foo.service. Часто,

Обратите внимание, что этот тип зависимости не означает, что другой модуль всегда должен быть в активном состоянии, когда он работает. В частности: неудачные проверки условий (такие как ConditionPathExists =, ConditionPathExists =,… - см. Ниже) не приводят к сбою при запуске задания модуля с зависимой от Требуется =. Кроме того, некоторые типы блоков могут деактивироваться самостоятельно (например, сервисный процесс может решить завершить работу чисто, или пользователь может отключить устройство), что не распространяется на блоки, имеющие зависимость Require =. Используйте тип зависимости BindsTo = вместе с After =, чтобы гарантировать, что юнит никогда не может быть в активном состоянии без конкретного другого юнита, также находящегося в активном состоянии (см. Ниже).

Со страницы freedesktop.org

Ваш сервис будет запущен только в том случае, если достигнут multi-user.target (я не знаю, что произойдет, если вы попытаетесь добавить его к этой цели?), И systemd попытается запустить display-manager.service перед вашим сервисом. , Если по какой-либо причине сбой display-manager.service произойдет, ваша служба все равно будет запущена (поэтому, если вам действительно нужен display-manager, используйте Requires=для этого). Однако, если multi-user.target не достигнут, ваш сервис не будет запущен.

Какой у вас сервис? Это система киосков? Интуитивно я полагаю, что вы хотите добавить свой сервис в multi-user.target (чтобы он запускался при запуске), и он строго зависел от display-manager.service через Requires=display-manager.service. Но это просто дикие догадки сейчас.


1

Развертывание нашего сервера использует LDAP, содержащий все идентификаторы пользователей и карты автомонтирования. Домашние каталоги пользователей монтируются по NFS, и пользователи обычно создают cronjobs @reboot с исполняемым кодом в своих домашних каталогах. Мы также используем sssd для кеша. Излишне говорить, что мы очень зависимы от возможности обеспечить детерминированный порядок загрузки для этой конфигурации. Мы разработали очень сжатую конфигурацию systemd и обнаружили неясный нюанс между параметрами раздела «хочет» и «требует».

Если у вас произошел сбой службы во время загрузки, и есть другая служба, зависящая от «require» для этой службы с параметром «restart = всегда», установленным в качестве опции службы, эта зависимая служба не будет перезапущена. Однако, если у вас есть «хочет» в качестве опции, зависимый сервис будет перезапущен, как и ожидалось.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.