Linuxサービスが動かないとき、再起動の前に確認する順番

Linux上のサービスが動かなくなったとき、最初に再起動したくなります。再起動で復旧することはありますが、同時に停止時の手掛かりが消えることもあります。

急いでいるときほど、闇雲にコマンドを増やさず、確認する順番を決めておくほうが安全です。

先に障害の範囲を確認する

「Webサイトが見えない」と「Webサーバーが停止している」は同じではありません。DNS、ロードバランサー、ネットワーク、アプリケーション、データベースなど、利用者とサービスの間には複数の要素があります。

最初に確認したいのは次の点です。

• いつから発生しているか
• 全利用者か、一部の経路だけか
• 対象ホストへ到達できるか
• 直前にデプロイや設定変更がなかったか
• 監視上、どの時点から異常になったか

対象を一台のLinuxホストへ絞れたら、サービスの状態を見ます。

1. systemctl statusで現在地を見る

systemctl status nginx --no-pager -l

ここではactiveかfailedかだけでなく、終了コード、直近のログ、起動時刻を見ます。サービス名は環境に合わせて置き換えます。

inactiveだから障害とは限りません。常駐を想定していないユニットや、別のユニットから必要時に起動されるものもあります。期待する状態を先に確認します。

2. journalctlで停止前後を確認する

journalctl -u nginx --since "30 minutes ago" --no-pager
journalctl -u nginx -b --no-pager

一行のエラーだけで判断せず、その前後を読みます。最後に表示されたエラーが根本原因ではなく、先に発生した設定不備や依存先の停止を受けた結果であることもあります。

時刻も重要です。アプリケーション、ロードバランサー、監視でタイムゾーンが違うと、同じ事象を別の時刻として追いかけることになります。

3. 設定を検証する

再起動する前に、サービスが提供する設定検証コマンドを使います。

nginx -t
apachectl configtest
sshd -t

すべてのサービスに同じコマンドがあるわけではありません。対象ソフトウェアの公式ドキュメントで確認します。設定ファイルを目視するだけでは、includeされた別ファイルや構文上の問題を見落とします。

4. リソースと依存先を見る

設定が正しくても、ディスク不足、メモリ不足、ファイルディスクリプター上限、依存先への接続失敗などで起動できない場合があります。

df -h
df -i
free -h
systemctl list-dependencies nginx

ディスク容量に余裕があってもinodeを使い切っていることがあります。ログや小さな一時ファイルが大量に作られる環境では、df -hだけで終わらせません。

5. 待受ポートとプロセスを確認する

ss -lntp
ps -ef

psの各列の意味とps -efの使い分けは当時のメモに、プロセスの停止とジョブ制御はこちらに書きました。ここで見たいのは列の読み方ではなく、その一覧から何を判断するかです。

別プロセスが同じポートを使用していないか、想定外の古いプロセスが残っていないかを確認します。プロセスが存在することと、正常にリクエストを処理できることは別なので、ローカルからヘルスチェックやHTTPリクエストも試します。

再起動するなら、目的を決める

ここまで確認した上で再起動する場合は、少なくとも次を記録します。

• 実行時刻
• 実行者
• 再起動前の状態とログ
• 再起動する理由
• 期待する結果
• 復旧しなかった場合の次の手順

再起動後はactive表示だけで完了にせず、利用者と同じ経路で機能確認します。再起動は復旧操作であって、原因分析そのものではありません。

今回の要点

1. 影響範囲と直前変更を確認する
2. systemctl statusで現在の状態を見る
3. journalctlで停止前後の流れを追う
4. 設定検証、リソース、依存先を確認する
5. プロセスと待受ポートを見る
6. 記録を残してから、必要なら再起動する
7. 利用者と同じ経路で復旧を確認する

再起動で直ると安心しますが、理由が分からないままなら、次の再起動予定が未定なだけです。サービスより先に、調査の手掛かりを再起動しないようにしたいところです。