Systemd: Потрібно проти хоче


18

Чи є різниця між Requires vs Wants у цільових файлах?

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

Дякую


2
Дивітьсяman systemd.unit
heemayl

Відповіді:


12

Як зазначив heemayl у коментарі, сторінка man відповідає на ваше запитання. З Інтернету:

Хоче =

Більш слабка версія Requires =. Одиниці, перелічені в цій опції, будуть запущені, якщо блок налаштування є. Однак, якщо перелічені одиниці не запускаються або не можуть бути додані до транзакції, це не впливає на обгрунтованість транзакції в цілому. Це рекомендований спосіб підключення пуску одного блоку до запуску іншого пристрою.

І вимагає =:

Налаштування залежності вимог від інших одиниць. Якщо цей пристрій активується, будуть також активовані перелічені тут одиниці. Якщо один з інших блоків вимкнеться або його активація не вдасться, цей пристрій буде вимкнено. Цей параметр може бути вказаний більше, ніж один раз, або кілька одиниць, розділених пробілом, можуть бути вказані в одному варіанті, в цьому випадку будуть створені залежності вимог для всіх перелічених імен. Зауважте, що залежність від вимог не впливає на порядок запуску чи зупинення послуг. Це потрібно налаштувати самостійно за допомогою параметрів After = або Before =. Якщо для підрозділу foo.service потрібна одиниця bar.service, налаштована за допомогою Requires =, і впорядкування не налаштовано з After = або Before =, тоді обидва блоки будуть запущені одночасно і без жодної затримки між ними, якщо foo.service активовано. Часто,

Зауважте, що цей тип залежності не означає, що інший блок завжди повинен перебувати в активному стані, коли цей блок працює. Зокрема: невдалі перевірки стану (наприклад, ConditionPathExists =, ConditionPathExists =,… - див. Нижче) не призводять до того, що завдання запуску одиниці з залежністю Requires = не завершує роботу. Також деякі типи пристроїв можуть деактивуватися самостійно (наприклад, сервісний процес може вирішити чисто вийти або користувач може відключити мережу від мережі), який не поширюється на одиниці, які мають залежність Requires =. Використовуйте тип залежності BindsTo = разом із After =, щоб переконатися, що одиниця може ніколи не перебувати в активному стані без певного іншого блоку, також в активному стані (див. Нижче).

Із сторінки freedesktop.org

Ваша послуга почнеться лише в тому випадку, коли досягнуто багатокористувацької цілі (я не знаю, що станеться, якщо ви спробуєте додати її до цієї цілі?), А systemd спробує запустити display-manager.service перед вашою службою . Якщо програма display-manager.service виходить з ладу з будь-якої причини, ваша послуга все одно буде запущена (тому, якщо вам дійсно потрібен менеджер дисплеїв, використовуйте Requires=для цього). Якщо все-таки багатоцільовий ціль не досягнуто, ваша послуга не буде запущена.

Яка ваша послуга? Це система кіоску? Інтуїтивно я вважаю, що ви хочете додати свою послугу до програми multi -user.target (тому її запускається при запуску), і це суворо залежить від display-manager.service via Requires=display-manager.service. Але це просто дикі здогадки.


1

Нашому серверному розгортанні використовується LDAP, що містить усі ідентифікатори користувачів та карти автоматичного набору. Домашні каталоги користувачів встановлені NFS, і користувачі, як правило, створюють @reboot cronjobs з виконуваним кодом у своїх домашніх каталогах. Ми також використовуємо sssd для кешу. Само собою зрозуміло, що ми маємо велику залежність від можливості забезпечити детермінований порядок завантаження для роботи цієї конфігурації. Ми розробили дуже лаконічну системну конфігурацію та виявили незрозумілий нюанс між параметрами розділу "хоче" та "вимагає".

Якщо у вас є збій служби під час завантаження, і є інша служба, залежна від "вимагає" на цій службі, "опція перезапуску = завжди", встановлена ​​як параметр послуги, ця залежна служба не перезапуститься. Якщо ж у вас є опція "хоче", залежна служба перезапуститься, як очікувалося.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.