systemdで順序サイクルをデバッグするための一般的な方法論

私は次のスレッドとおそらくそれに対する答えを知っています。回答を除き、一般的な意味での回答ではありません。1つの特定のケースで問題が何であったかがわかりますが、一般的にはわかりません。

私の質問は、一般的な方法で注文サイクルをデバッグする方法はありますか？たとえば、サイクルと、あるユニットを別のユニットにリンクするものを記述するコマンドがありますか？

たとえば、私は以下を持っています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-typeユニットは暗黙的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

リンク：

• systemd-analyze（1）
• ドット（1）

ステップ1：default.targetの検証コマンドを実行します

systemd-analyze verify default.target

ステップ2：「systemd Breaking Ordering Cycling by Job」というメッセージに記載されているサービスまたはターゲットを確認し、完全な依存関係リストを表示します

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の無限のサイクルを引き起こしていることを意味します。

治療法は簡単です-変更の単語を「後」に「前に」、またその逆必要に応じて。