загальна методологія налагодження циклів упорядкування в systemd

Мені відомо про наступну нитку і нібито відповідь на неї . За винятком відповіді - це не відповідь у загальному сенсі. Він розповідає, у чому проблема була в одному конкретному випадку, але не в цілому.

Моє запитання: чи є спосіб налагодження циклів упорядкування загальним способом? Наприклад: чи існує команда, яка описує цикл і що пов'язує один блок на інший?

Наприклад, у мене є наступне journalctl -b(будь ласка, ігноруйте дату, у моєї системи немає RTC для синхронізації часу):

Jan 01 00:00:07 host0 systemd[1]: Found ordering cycle on sysinit.target/start
Jan 01 00:00:07 host0 systemd[1]: Found dependency on local-fs.target/start
Jan 01 00:00:07 host0 systemd[1]: Found dependency on cvol.service/start
Jan 01 00:00:07 host0 systemd[1]: Found dependency on basic.target/start
Jan 01 00:00:07 host0 systemd[1]: Found dependency on sockets.target/start
Jan 01 00:00:07 host0 systemd[1]: Found dependency on dbus.socket/start
Jan 01 00:00:07 host0 systemd[1]: Found dependency on sysinit.target/start
Jan 01 00:00:07 host0 systemd[1]: Breaking ordering cycle by deleting job local-fs.target/start
Jan 01 00:00:07 host0 systemd[1]: Job local-fs.target/start deleted to break ordering cycle starting with sysinit.target/start

де cvol.service (введений і який порушує цикл):

[Unit]
Description=Mount Crypto Volume
After=boot.mount
Before=local-fs.target

[Service]
Type=oneshot
RemainAfterExit=no
ExecStart=/usr/bin/cryptsetup open /dev/*** cvol --key-file /boot/***

[Install]
WantedBy=home.mount
WantedBy=root.mount
WantedBy=usr-local.mount

За даними journalctl, cvol.service хоче basic.service, за винятком того, що це не відбувається, принаймні не очевидно. Чи є команда, яка б демонструвала, звідки походить це посилання? І взагалі, чи є команда, яка б знаходила цикли і показувала, звідки бере початок кожна ланка циклу?

Чи є команда, яка б демонструвала, звідки походить це посилання?

Найближче, що ви можете зробити, це те systemctl show -p Requires,Wants,Requisite,BindsTo,PartOf,Before,After cvol.service, що покаже отримані (ефективні) списки залежностей для даної одиниці.

чи є команда, яка знайшла б цикли та показала б, звідки походить кожна ланка циклу?

Наскільки мені відомо, такої команди немає. Насправді systemd нічого не допомагає в налагодженні циклів замовлення (зітхання).

За даними journalctl, cvol.service хоче basic.service, за винятком того, що це не відбувається, принаймні не очевидно.

По- перше, вимога (залежностей Wants=, Requires=, і BindsTo=т.д.) не залежить від залежностей упорядкування ( Before=і After=). Те, що ви бачите тут, - це цикл залежності впорядкованості , тобто він не має нічого спільного з Wants=тощо.

По-друге, існує ряд "залежностей за замовчуванням", створених між одиницями певних типів. Вони контролюються DefaultDependencies=директивою в [Unit]розділі (який включений за замовчуванням ).

Зокрема, якщо ця директива явно не вимкнена, будь-яка .serviceодиниця типу отримує неявні Requires=basic.targetта After=basic.targetзалежності, що саме ви бачите. Це зафіксовано в systemd.service (5) .

Ви можете уявити собі цикл з командами systemd-analyze verify, systemd-analyze dotі GraphViz dot інструмент:

systemd-analyze verify default.target |&
perl -lne 'print $1 if m{Found.*?on\s+([^/]+)}' |
xargs --no-run-if-empty systemd-analyze dot |
dot -Tsvg >cycle.svg

Ви повинні побачити щось подібне:

Тут ви можете побачити цикл: c.service->b.service->a.service->c.service

Color legend: 
    black     = Requires
    dark blue = Requisite
    dark grey = Wants
    red       = Conflicts
    green     = After

Посилання:

• системний аналіз (1)
• крапка (1)

крок 1: запустіть команду підтвердження для default.target

systemd-analyze verify default.target

крок 2: спостерігайте, яку службу чи ціль згадують у повідомленні "Система порушення циклу замовлень шляхом видалення завдання" та відображайте повний список залежностей

systemctl show -p Requires,Wants,Requisite,BindsTo,PartOf,Before,After <service or target name mentioned in the "breaking cycle" message>

крок 3: перегляньте групи "після" і "до" всередині сервісного або цільового файлу, як правило, визначеного в

/lib/systemd/system

і знайти послуги або цілі, які, як відомо, є послідовними, але вони є у вихідному порядку для цього.

приклад:

dbus.service

зазвичай ринок "після"

multi-user.target

але "до"

sockets.target

таку залежність можна було легко помітити, зателефонувавши

systemctl list-dependencies default.target

однак якщо файл

/lib/systemd/system/dbus.service

містять рядки типу:

Before=multi-user.target

або

After=sockets.target

або і те й інше, означає, що dbus.service визначається вихідним і викликає нескінченний системний цикл.

лікування просто - змінити слово «Після» до «До» і навпаки , якщо це необхідно.