универсальная методология для отладки циклов упорядочивания в systemd
Я предположу что дополнительное поле от n строки file2 должен быть добавлен к последнему n строки file1:
awk -F, -v OFS=, 'FNR==NR {a[FNR]=$3; next} {print $0, a[FNR]}' <(tac file2) <(tac file1) | tac
paste -d, <(tac file1) <(cut -d, -f3- <(tac file2)) | tac
Они решение добавляют запаздывающую запятую к первой строке. Можно удалить его путем передачи по каналу вышеупомянутого через sed 's/,$//'
Есть ли команда, которая продемонстрировала бы, что эта ссылка получена из?
Самое близкое, что вы можете сделать, это Systemctl Show -P требует, желает, реквизит, Bindsto, Partof, Перед, после CVOL.Service , который покажет полученные (эффективные) списки зависимостей для данного блока.
Есть ли команда, которая найдет циклы и показывает, где каждая ссылка в цикле происходит?
Для моих знаний нет такой команды. На самом деле SystemD предлагает нечего, чтобы помочь в циклах отладки заказа (вздох).
Согласно JournctCtl, CVOL.Service хочет Basic. Service, за исключением того, что это не так, по крайней мере, не очевидно.
Во-первых, зависимости требований ( требует = , требуется , , BindSto = и т. Д.) Независимо от заказа зависит от ( до = и после = ). То, что вы видите здесь, - это заказа Цикл зависимости, I. добиваться Это не имеет ничего общего с желанием = и т. Д.
Вторым, существует ряд «зависимостей по умолчанию», созданные между единицами определенных типов. Они контролируются defaultdependonds = Директивой в разделе [единица] [[115125] [, включенные по умолчанию ).
, в частности, если эта дирекция не будет не отключена, любой . Устройство . Требуется неявный , требует = Basic.target и после = basic.target Зависимости, что именно то, что вы видите. Это задокументировано в SystemD.Service (5) .
Вы можете визуализировать цикл с командами , systemd-анализируют, проверяют , systemd-анализируют точку и инструмент GraphViz точки :
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 :запустить команду проверки для default.target
systemd-analyze verify default.target
шаг 2 :наблюдайте за тем, какая служба или цель упоминается в сообщении «Systemd прерывает цикл упорядочения путем удаления задания» и отображает полный список зависимостей
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 определен как исходящий и вызывает бесконечный цикл systemd.
лечение простое -заменить слово "После" на "До" и наоборот -наоборот, если необходимо.