サービスが落ちていないのに動いていない時の調査手順（Linux編）

URLをコピーしました！

Linuxサーバー運用中、以下のような状況に遭遇したことはないでしょうか。

systemctl status は active (running)
プロセスも存在している
それなのにレスポンスが返らない

この状態は一見すると「正常」に見えますが、

実際には処理がどこかで止まっている

ことがほとんどです。

本記事では、

サービスが「生きているように見える」理由
どこで止まっているかを切り分ける手順
どうなれば解決と判断できるか

を、Linux実務でそのまま使える調査フローとして解説します。

まず前提：プロセスがある ≠ 正常稼働

Linuxでは、

プロセスが存在する
systemdがrunningと表示する

だけで、

そのプロセスが仕事をしている保証はありません。

以下のような状態でも、サービスは「落ちていない」扱いになります。

I/O待ちで完全に止まっている
ロック待ちで進めない
外部通信待ちで固まっている

Step1：systemctlで「見た目の状態」を確認

systemctl status サービス名

ここで確認するポイントは、

active (running) になっているか
Main PID が存在しているか
再起動ループに入っていないか

active であれば、 「systemd的には問題なし」というだけです。

Step2：本当に処理が進んでいるかを確認

CPUを使っているか

top -Hp PID

以下の場合は要注意です。

CPU使用率がほぼ0
スレッド数はあるが動いていない

CPUを使っていない = 暇、ではなく、 待たされている可能性があります。

プロセス状態を見る

ps -o pid,stat,cmd -p PID

特に見るべきは STAT です。

D：I/O待ち（ほぼ停止）
S：スリープ中

D 状態が続く場合、 外から止めることはほぼ不可能です。

Step3：I/O待ち・ブロックを疑う

vmstat 1

以下が揃っていれば、

b（Blocked）が増えている
wa（I/O wait）が出ている

サービスが動いていない原因は ディスクI/O待ちです。

この場合、サービス自体を再起動しても 根本解決にはなりません。

Step4：ログは出ているか（journalctl）

journalctl -u サービス名 --since "YYYY-MM-DD HH:MM"

見るべきポイントは、

エラーが出ていないか
ログが途中で止まっていないか

ログが出ていない場合、

処理が入口で詰まっている
外部依存で待っている

可能性が高くなります。

Step5：ネットワーク・外部依存を疑う

以下のケースでは、サービスは「落ちていないが動かない」状態になります。

外部API応答待ち
DBロック待ち
DNS名前解決待ち

確認例：

ss -antp | grep PID

接続が

ESTABLISHED のまま動かない
SYN-SENT で止まっている

場合、通信待ちが原因です。

やってはいけない対処

原因不明のまま再起動を繰り返す
「そのうち治る」と放置する

これらは、

問題を隠すだけで再発を招きます。

どうなれば「解決」と判断できるか

以下が揃えば解決です。

処理が止まっていた原因が特定できた
I/O・通信待ちが解消された
CPU・ログが正常に動き出した

単に再起動して直っただけでは、 解決とは言えません。

まとめ

running表示でも中身は止まっていることがある
CPU未使用＝正常ではない
vmstat・journalctl・ss が切り分けの軸
「どこで待っているか」を見つけるのが最重要

サービスが落ちていないのに動かない場合、

原因は必ず「待ち」です。

正しい順序で見れば、必ず辿り着けます。