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

systemd サービス障害のトラブルシューティング：システム管理者のための実践ガイド

systemd サービスは最新の Linux システムの基盤ですが、障害が発生することがあります。この実践ガイドは、システム管理者が一般的な systemd サービス障害を体系的にトラブルシューティングして解決できるようにします。`journalctl` を効果的に使用してログを分析し、依存関係の問題を診断し、終了コードを解釈し、Web サーバー、データベースなどの具体的な修正を適用して、サービス機能を迅速に復旧する方法を学びます。

60 ビュー

systemdサービスの障害トラブルシューティング: システム管理者のための実践ガイド

systemdは、多くのLinuxディストリビューションで採用されている現代的なinitシステムおよびサービスマネージャーです。速度、並列化、依存関係管理において大きな利点を提供する一方で、systemdサービスは依然として障害が発生する可能性があります。システム管理者として、これらの障害を体系的に診断し解決できることは、極めて重要なスキルです。このガイドでは、一般的なsystemdサービスの問題をトラブルシューティングするための実践的なアプローチを提供し、根本原因を迅速に特定してサービス機能を回復できるようにします。

systemdがサービスをどのように管理するか、および検査に利用できるツールを理解することは、効率的なトラブルシューティングの鍵です。journalctlを使用したsystemdログの分析、サービス依存関係の理解、終了コードの解釈、およびサービス障害につながる一般的な落とし穴について深く掘り下げていきます。これらの体系的な手順に従うことで、推測に頼るのをやめ、重要なサービスを効率的にオンラインに戻すことができます。

systemdサービス障害の理解

systemdサービスが起動に失敗したり、予期せずクラッシュしたりする場合、多くの場合、さまざまな理由によるものです。これらは、単純な設定エラー、依存関係の欠落、リソース制限、サービス自体内のバグにまで及びます。systemdは、これらの障害の正確な原因を特定するのに役立つ堅牢なメカニズムを提供します。

サービス障害の一般的な原因:

  • 設定エラー: サービスの.serviceユニットファイルまたは関連する設定ファイル内の不正確な設定。
  • 依存関係の欠落: サービスが、利用できないかまだ起動していない他のシステムリソース（ネットワーク、他のサービス、特定のファイルシステムなど）に依存している。
  • リソース枯渇: サービスが、システムが提供できる以上のメモリ、CPU、またはディスクI/Oを必要とする。
  • 権限の問題: サービスプロセスに、必要なファイル、ディレクトリ、またはネットワークポートにアクセスするための必要な権限がない。
  • サービス内のバグ: アプリケーション自体に、起動時または操作中にクラッシュするバグがある。
  • データ破損: サービスによって使用される重要なデータファイルが破損している。
  • ネットワークの問題: ネットワークインターフェース、DNS、またはファイアウォールルールに関する問題が、サービスがポートにバインドしたり通信したりするのを妨げる。

ステップ1: サービス状態の検査

障害が発生したサービスをトラブルシューティングする際の最初のステップは、現在の状態を確認することです。systemdのsystemctlコマンドがこれを行うための主要なツールです。

systemctl statusの使用

systemctl status <service_name>.serviceコマンドは、サービスの現在の状態、最近のログエントリ、およびプロセス情報の簡潔な概要を提供します。

sudo systemctl status nginx.service

例の出力（失敗したサービス）:

● nginx.service - A high performance web server and reverse proxy
     Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
     Active: failed (result=exit-code) since Tue 2023-10-27 10:30:00 UTC; 1min ago
       Docs: man:nginx(8)
    Process: 1234 ExecStart=/usr/sbin/nginx -g daemon on; master_process on; (code=exited, status=1/FAILURE)
   Main PID: 1234 (code=exited, status=1/FAILURE)

Oct 27 10:30:00 your-server systemd[1]: Starting A high performance web server and reverse proxy...
Oct 27 10:30:00 your-server nginx[1234]: nginx: [emerg] bind() to port 80 failed (98: Address already in use)
Oct 27 10:30:00 your-server systemd[1]: nginx.service: Main process exited, code=exited, status=1/FAILURE
Oct 27 10:30:00 your-server systemd[1]: Failed to start A high performance web server and reverse proxy.

systemctl status出力で探すべき重要な情報:

  • Active:: この行は現在の状態を示します。failedは私たちが関心のある状態です。failed (result=exit-code)またはfailed (result=oom-kill)と表示されることもあります。resultはしばしば手がかりを提供します。
  • Process:: systemdが実行しようとしたプロセスに関する詳細。code=exited, status=...と表示されている場合、これは重要です。
  • ログエントリ: 最新のログ行には、サービスからの直接のエラーメッセージが含まれていることがよくあります。

ステップ2: journalctlによるログの分析

journalctlコマンドは、systemdジャーナルからログをクエリおよび表示するためのsystemdの強力なツールです。サービスが失敗した理由に関する詳細な洞察を得るために不可欠です。

サービスのための基本的なjournalctlの使用法

特定のサービスのログを表示するには、-uフラグを使用します。

sudo journalctl -u <service_name>.service

リアルタイムでログを追跡するには:

sudo journalctl -f -u <service_name>.service

最後の起動からのログを表示するには（起動中に失敗したサービスに役立ちます）:

sudo journalctl -b -u <service_name>.service

特定の時刻以降のログを見るには:

sudo journalctl --since "2023-10-27 10:00:00" -u <service_name>.service

journalctl出力の解釈

エラーメッセージ、スタックトレース、またはアプリケーションやsystemd自体によって報告された特定のエラーコードを探します。systemctl statusからの例の出力には、すでに主要なエラーが表示されていました: bind() to port 80 failed (98: Address already in use)。これは、別のプロセスがすでにポート80を使用しており、Nginxの起動を妨げていることを明確に示しています。

ヒント: サービスが非常に詳細なログを出す場合、出力を制限できます:

sudo journalctl -n 50 -u <service_name>.service  # 最後の50行を表示

ステップ3: サービス依存関係と要件の確認

systemdサービスは、他のサービスまたはシステムリソースが利用可能であることに依存していることがよくあります。依存関係が満たされていない場合、サービスは起動しません。

依存関係の表示

systemctl catを使用してサービスの依存関係を検査し、Requires=, Wants=, After=, Before=, PartOf=のようなディレクティブを確認できます。

systemctl cat <service_name>.service

例えば、データベースサービスはRequires=network-online.targetとAfter=network-online.targetを持つかもしれません。データベースが起動しようとしたときにネットワークが完全に稼働していない場合、失敗します。

欠落している依存関係の確認

systemctl statusはしばしば依存関係の問題を示しますが、必要なサービスがアクティブであるかを明示的に確認することは役立ちます。

systemctl is-active <dependency_service_name>.service

必要なサービスがマスクされているか停止している場合、ターゲットサービスの起動を妨げる可能性があります。

systemctl list-dependencies <service_name>.service

このコマンドは完全な依存関係ツリーを表示します。

ステップ4: 終了コードの理解

サービスが失敗すると、特定の終了コードで終了します。このコードは、失敗の性質に関する貴重な情報を提供します。

  • 終了コード 0: 成功。
  • 終了コード 1-127: 一般的なエラー。具体的な意味はアプリケーションに依存します。
  • 終了コード 127: コマンドが見つかりません（多くの場合、ExecStartパスが不正確であるか、実行可能ファイルがないため）。
  • 終了コード 137: SIGKILLによって強制終了されました（多くの場合、oom-kill - メモリ不足のため）。
  • 終了コード 139: SIGSEGVによって強制終了されました（セグメンテーション違反）。

systemctl statusの出力から、status=1/FAILUREを確認しました。これは一般的な失敗であり、その前のログメッセージは、ステータス1で失敗した理由を理解するために不可欠です。

OOM Killの特定

systemctl statusがfailed (result=oom-kill)と表示する場合、システムがメモリ不足に陥ったため、LinuxのOOM（Out-Of-Memory）キラーがサービスのプロセスを終了したことを意味します。

これを確認するには、journalctlまたはdmesgで関連するメッセージを見つけることができます。

dmesg | grep -i oom

OOMエラーのトラブルシューティング

  • システムRAMの増設: 可能な場合。
  • メモリ使用量の削減: サービスまたは他の実行中のプロセスを最適化します。
  • スワップの設定: 十分なスワップスペースが利用可能であることを確認します。
  • サービスメモリ制限の調整: サービスユニットファイルでsystemdのcgroupオプション（例: MemoryMax=）を使用してメモリ消費を制限します。ただし、これによりサービス自体がOOM-killされるのではなく、正常にクラッシュすることがあります。

ステップ5: サービス固有の一般的な問題と修正

上記の手順は一般的ですが、特定のサービスには一般的な障害モードがあります。

ウェブサーバー (Nginx, Apache)

  • ポートが既に使用中: 例で示したように、別のプロセスがポート80または443でリッスンしている可能性があります。sudo ss -tulnp | grep :80を使用して、競合するプロセスを見つけます。
  • 設定構文エラー: ウェブサーバーの設定テストを実行します（例: sudo nginx -t または sudo apachectl configtest）。
  • 不足しているSSL証明書: 証明書ファイルが存在し、読み取り可能であることを確認します。

データベース (MySQL, PostgreSQL)

  • データディレクトリの権限: データベースユーザーがデータディレクトリへの正しい読み書きアクセス権を持っていることを確認します。
  • 破損したデータファイル: バックアップからの復元、またはデータベース固有のリカバリツールの使用が必要になる場合があります。
  • ディスク容量不足: データベースはかなりのディスク容量を消費する可能性があります。

ネットワークサービス

  • 不正確なIPアドレスまたはホスト名: ネットワーク設定を確認します。
  • ファイアウォールルール: 必要なポートが開いていることを確認します。
  • DNS解決の問題: /etc/resolv.confとネットワーク接続を確認します。

ステップ6: 高度なトラブルシューティング技術

サービスの再有効化と再起動

変更を加えた後、サービスを再有効化して再起動することを忘れないでください。

sudo systemctl daemon-reload # systemdマネージャー設定をリロード
sudo systemctl enable <service_name>.service # 起動時に開始するようにする
sudo systemctl restart <service_name>.service

systemctl --failedの使用

このコマンドは、現在失敗状態にあるすべてのユニットをリストします。

systemctl --failed

リソース制限 (ulimit) の確認

一部のサービスは、オペレーティングシステムレベルのリソース制限に達すると失敗する可能性があります。サービスを実行するユーザーとしてulimit -aで制限を確認するか、ユニットファイル内のsystemd独自のリソース制御ディレクティブを確認します。

デバッグフラグ

多くのアプリケーションには、.serviceファイルのExecStart行のコマンドライン引数を通じて有効にできるデバッグモードまたは詳細ログ記録があります。アプリケーションのドキュメントを参照してください。

結論

障害が発生したsystemdサービスのトラブルシューティングは、利用可能なツールと一般的な障害点を理解することに依存する体系的なプロセスです。systemctl status、journalctlを活用し、サービス依存関係と終了コードを理解することで、ほとんどのサービス障害を効率的に診断し解決できます。トラブルシューティングしているサービスの特定のドキュメントを参照することを忘れないでください。それは、一般的な問題とその解決策に関するさらなる洞察を提供するかもしれません。