DevOpsナレッジハブ
DevOpsナレッジハブ

Systemd依存関係の理解：ユニット競合の防止と修正

信頼性の高いサービス起動を保証し、起動障害を防ぐためにsystemdの依存関係管理をマスターしましょう。このガイドでは、必須の依存関係ディレクティブ（`Requires=`、`After=`、`Wants=`）を詳述し、順序の問題を診断するための`systemctl list-dependencies`のような実用的なコマンド、そしてLinuxシステムサービスで一般的なユニット競合を修正するための実行可能なステップを提供します。

34 ビュー

Systemdの依存関係を理解する：ユニットの競合を防ぎ、修正する

Systemdは、主要なLinuxディストリビューションのほとんどで使われている最新のシステムおよびサービスマネージャーです。その堅牢な設計は、サービス、マウント、ソケット、その他のシステムコンポーネントを定義するためにユニットファイルに大きく依存しています。これらのコンポーネントを管理する上で重要な側面が、依存関係の解決です。依存関係が誤って設定されていると、サービスが起動に失敗したり、間違った順序で起動したり、互いに競合したりして、サービスの不安定化やブートの失敗につながる可能性があります。

このガイドでは、systemdの依存関係メカニズムについて深く掘り下げます。サービス間の関係を確立するために使用される主要なディレクティブ、依存関係に関連する起動の問題を診断するためのテクニック、および安定した予測可能なシステムブートシーケンスを確保するための一般的なユニットの競合を解決するための実践的な方法を探ります。

基礎：Systemdユニットの依存関係ディレクティブ

Systemdは、ユニットファイル（通常、/etc/systemd/system/または/lib/systemd/system/に配置）内で特定のディレクティブを使用して、あるユニットがいつ別のユニットを起動、停止、または待機すべきかを指示します。これらのディレクティブを理解することが、依存関係を正しく管理するための第一歩です。

コアな順序付けディレクティブ

これらのディレクティブは、他のユニットとの相対的な順序を制御します。

  • Requires=：
    • 強い依存関係を確立します。必要なユニットの起動に失敗した場合、現在のユニットも失敗します。
    • 暗黙的にPartOf=を意味します。
  • Wants=：
    • 弱い依存関係です。希望するユニットが失敗しても、現在のユニットは起動を試みます。これはオプションの依存関係に使用されます。
  • BindsTo=：
    • Requires=に似ていますが、停止に関してはより強力です。バインドされたユニットが（何らかの理由で）停止した場合、現在のユニットも停止します。
  • PartOf=：
    • 現在のユニットが別のユニットの従属部分であることを示します（例：メインサービスに関連する特定のソケットアクティベーション）。上位ユニットが停止すると、従属ユニットも停止します。

コアな起動同期ディレクティブ

これらのディレクティブは、依存するユニットが必要なユニットに対していつ起動すべきかを指示します。

  • After=：
    • 現在のユニットが、リストされたユニットが正常に起動した後（または指定された状態、通常はactiveに到達した後）にのみ起動することを指定します。
  • Before=：
    • 現在のユニットが、リストされたユニットの前に起動することを指定します。

ベストプラクティス： 通常のサービス起動順序付けでは、Wants=とAfter=を組み合わせるのが最も一般的で安全なパターンです。Requires=は、依存関係の失敗が依存するサービスの失敗を必ず引き起こすような場合にのみ使用すべきです。

例：サービスファイルでの依存関係の定義

PostgreSQL（postgresql.service）によって管理されるデータベースと通信する必要があるカスタムアプリケーションサービス、myapp.serviceを考えます。

# /etc/systemd/system/myapp.service
[Unit]
Description=私のカスタムアプリケーション

# PostgreSQLが起動してから自分を起動する
Requires=postgresql.service
After=postgresql.service

[Service]
ExecStart=/usr/bin/myapp

[Install]
WantedBy=multi-user.target

依存関係の問題の診断

サービスが起動に失敗した場合、systemdは通常ログに十分な情報を提供しますが、依存関係の連鎖が根本原因を不明瞭にすることがあります。ここでは、トラブルシューティングに不可欠なツールとコマンドを紹介します。

1. ユニットの状態とログの確認

基本的な出発点は、起動に失敗した直後にサービスの状態を確認し、そのログをレビューすることです。

# 依存関係の失敗がよく言及されている全体的な状態を確認する
systemctl status myapp.service

# ユニットに特に関連する詳細なログを表示する
journalctl -u myapp.service --since "5 minutes ago"

2. 依存関係ツリーの分析

Systemdは、何が何を待っているのかを正確に確認できる強力な視覚化ツールを提供します。

systemctl list-dependencies

このコマンドは、指定されたユニットによって必要とされる、または望まれるユニットを、依存関係チェーン全体をたどって表示します。

myapp.serviceが起動するために何を必要とするかを確認するには：

# 前方依存関係（自分より先に起動する必要があるもの）
systemctl list-dependencies --after myapp.service

# 後方依存関係（自分に依存しているもの）
systemctl list-dependencies --before myapp.service

systemctl graphical-view（利用可能/設定されている場合）

通常、視覚化グラフ（例：SVGやDOT形式での出力）に使用されますが、構造を理解することは循環依存関係を追跡するのに役立ちます。

3. 競合と順序付けの問題の検出

依存関係の競合は、サービスが早すぎる起動や予期せぬ停止によって失敗するとして現れることがよくあります。

循環依存関係： これは最も危険な競合であり、ユニットAがBを必要とし、ユニットBがAを必要とする場合です。Systemdはこれを解決しようとしますが、多くの場合、一方または両方のユニットがfailedまたはactivatingの状態のまま無限に留まります。

システム全体にわたる潜在的な問題を見つけるには、順序付けに関連する特定の失敗メッセージをログで検索できます。

journalctl -b | grep -E "failed|refused to start|dependency was not satisfied"

一般的な依存関係の問題の修正

一度特定された依存関係の問題は、関連するユニットファイルのディレクティブを調整することで解決できます。

シナリオ1：前提条件が準備できる前にサービスが起動する

症状： アプリケーションログにデータベース接続エラーが表示されるが、postgresql.serviceがsystemctl statusではactiveと表示される。

診断： サービスがAfter=を使用しているものの、十分強力な順序付けメカニズムではないか、または前提条件となるサービスが初期化シーケンスを完了しているが、そのソケット/ポートがまだリッスン状態になっていない可能性があります。

解決策： サービスがネットワークソケットまたはデバイスが完全に利用可能であることに依存している場合、ソケットベースのアクティベーションの使用を検討するか、それが不可能な場合は、Requires=とAfter=を使用しているか、または利用可能であれば、前提となるサービスが'active'と報告した後に特定の条件をチェックするようにしてください。

シナリオ2：競合する起動/停止順序

症状： システムを停止すると、重要なプロセスがハングしたり、突然失敗したりする。

診断： これは、BindsTo=の誤用、または兄弟サービスにおけるBefore=とAfter=ディレクティブ間の複雑な相互作用を示していることが多いです。

解決策： 兄弟サービス（例：同じターゲットによって起動されるサービス）を確認してください。サービスAがサービスBの実行中に実行されなければならない場合は、BindsTo=またはRequires=を使用していることを確認してください。サービスAがサービスBがクリーンアップを開始する前にタスクを完了する必要がある場合は、After=の順序が正しいことを確認してください。

シナリオ3：不要な依存関係の削除

症状： 不要なサービスが起動チェーンに引き込まれるため、システムの起動が遅い。

診断： オプションの接続のみが必要な場合にRequires=を使用していた可能性があります。

解決策： Requires=をWants=に変更してください。サービスが機能するために依存関係を絶対的に必要としない場合、Wants=は依存関係が失敗したりマスクされたりしてもシステムが続行することを許可します。

# 変更前（厳しすぎる）
Requires=optional_logging.service

# 変更後（より良い）
Wants=optional_logging.service
After=optional_logging.service

変更の適用とリロード

ユニットファイルを変更するたびに、変更をテストする前にsystemdに設定をリロードするよう指示する必要があります。

# 1. systemdマネージャー設定をリロードする
sudo systemctl daemon-reload

# 2. 影響を受けるサービスを再起動する
sudo systemctl restart myapp.service

# 3. 状態を確認する
systemctl status myapp.service

まとめと次のステップ

Systemdの依存関係管理は、安定したサービスオーケストレーションの根幹をなします。Requires/Wants（包含のため）とAfter/Before（順序付けのため）の相互作用を習得することで、管理者はブートプロセスを正確に制御できます。トラブルシューティングを行う際は、常にsystemctl statusから始め、systemctl list-dependenciesを活用して、障害の原因となっているチェーンを視覚化してください。一貫性のある、適切に定義されたユニットファイルは、予測可能なシステム動作につながり、ブート時または実行時の予期せぬサービス停止を最小限に抑えます。