Linuxのプロセスが応答しないときの確認方法｜ps・top・killで原因を調べる

Byinfosugars

Linuxサーバーでアプリケーションが応答しなくなったり、コマンドが終了しなかったりすることがあります。

CPU使用率が高い場合もあれば、処理が止まったように見えるのにCPUをほとんど使っていない場合もあります。また、killコマンドを実行してもプロセスが終了しないケースもあります。

このようなときは、すぐにプロセスを強制終了するのではなく、プロセスの状態・CPUやメモリの使用状況・関連するログを順番に確認することが重要です。

Linuxのプロセスが応答しない主な原因

プロセスが応答しないように見える場合、いくつかの原因が考えられます。

原因主な症状確認するポイント
CPU負荷が高い処理が遅い、応答が返らないtop、ps
メモリ不足処理の遅延、プロセスの終了free、journalctl
ディスクI/Oの遅延ファイル操作や処理が止まったように見えるiostat、プロセス状態
ネットワークや外部サービスの応答待ち接続処理が終わらないアプリケーションログ、接続先
D状態になっているkillを実行しても終了しないps、top
アプリケーション内部の問題特定の処理だけ進まないアプリケーションログ

原因によって対処方法が異なるため、まずは対象プロセスを特定します。

psでプロセスの状態を確認する

対象のプロセスを確認するには、psコマンドを使います。

ps aux

特定のアプリケーションを探す場合は、次のように実行します。

ps aux | grep nginx

ただし、grep自身も検索結果に表示されることがあります。

プロセス名や状態を確認したい場合は、次の形式も便利です。

ps -eo pid,ppid,stat,%cpu,%mem,etime,comm

主に確認する項目は次のとおりです。

  • PID：プロセスID
  • PPID：親プロセスのID
  • STAT：プロセスの状態
  • %CPU：CPU使用率
  • %MEM：メモリ使用率
  • ETIME：起動してからの経過時間

特定のプロセスが長時間動作している場合は、CPU使用率や状態が変化しているかも確認します。

topでCPUやメモリの状況を調べる

サーバー全体の負荷を確認するには、topが役立ちます。

top

CPU使用率が高いプロセスや、メモリを多く使用しているプロセスを確認できます。

例えば、特定のプロセスがCPUを継続的に大量使用している場合、処理が集中している可能性があります。

一方、CPU使用率が低いのに処理が進まない場合は、ディスクI/Oやネットワーク、外部サービスの応答待ちなども調べる必要があります。

CPU使用率が低いからといって、プロセスが正常とは限りません。

killで終了できるか確認する

プロセスが明らかに不要な状態で、終了しても問題ないと判断できた場合は、まず通常の終了シグナルを送ります。

kill PID

PIDは対象プロセスの実際の番号に置き換えてください。

通常のkill PIDは、デフォルトでSIGTERMを送信します。これはプロセスに終了を要求するシグナルで、アプリケーションが後処理を行って終了できるようにする方法です。

プロセスがすぐに消えない場合は、少し時間を置いて状態を再確認します。

ps -p PID -o pid,stat,etime,cmd

終了していないからといって、すぐに強制終了するのは避けてください。データベースやファイルを書き込み中のプロセスを強制終了すると、処理への影響が出る可能性があります。

kill -9でも終了しない場合

通常の終了要求でプロセスが終了せず、影響を確認したうえで強制終了が必要な場合は、次のコマンドを使えます。

kill -9 PID

これはSIGKILLを送信し、プロセスに終了処理を行う機会を与えずに終了させる方法です。

ただし、強制終了は最初に試す方法ではありません。

アプリケーションの後処理が行われないため、ファイルやデータベースへの書き込み中などは注意が必要です。

また、kill -9を実行しても、プロセスがすぐに消えないことがあります。その場合は、プロセスの状態を確認してください。

D状態のプロセスは注意が必要

psのSTAT欄にDが表示されている場合、プロセスは通常、割り込みできないカーネル内の待機状態にあります。一般に、ディスクI/Oやネットワークファイルシステムなどの処理待ちで見られることがあります。

確認例：

ps -eo pid,stat,wchan:24,comm

STATがDのプロセスがある場合は、関連するストレージやファイルシステムの状態を調べます。

例えば、次のような情報を確認します。

dmesg | tail -n 50

権限や環境によっては、dmesgの出力が制限される場合があります。その場合は、システムログも確認してください。

sudo journalctl -k -n 50

D状態は単にアプリケーションが固まっている場合とは異なります。kill -9を実行しても、カーネル内の待機が解消されるまでプロセスが終了しないことがあります。

この場合は、ストレージ障害やI/O遅延、マウント先の問題など、待機の原因を調査することが重要です。

ログから原因を調べる

プロセスが応答しなくなった時刻が分かる場合は、同じ時間帯のログを確認します。

systemdで管理されているサービスなら、次のコマンドが使えます。

sudo journalctl -u サービス名 --since "30 minutes ago"

例えば、Nginxのログを確認する場合は次のとおりです。

sudo journalctl -u nginx --since "30 minutes ago"

アプリケーションによっては、独自のログファイルにエラーが記録されている場合もあります。

ログでは、次のような情報を探します。

  • タイムアウトや接続エラー
  • メモリ不足に関するメッセージ
  • ディスクやファイルシステムのエラー
  • データベース接続の失敗
  • 同じエラーの繰り返し

エラーが見つかった場合は、プロセスを終了するだけでなく、その前後に何が起きていたのかを確認します。

プロセスが応答しないときの確認手順

実際にトラブルが発生したら、次の順番で調査すると原因を整理しやすくなります。

  1. psで対象プロセスのPIDと状態を確認する
  2. topでCPU・メモリの使用状況を確認する
  3. STATがDなら、ディスクI/Oやカーネルログを調べる
  4. サービスのログからエラーやタイムアウトを確認する
  5. 終了しても問題ないことを確認し、必要に応じてSIGTERMを送る
  6. 強制終了が必要な場合は影響を確認してからSIGKILLを検討する
  7. 原因を解消したうえで、サービスが正常に動作するか確認する

原因が分からないままプロセスを終了すると、障害の手掛かりを失ったり、別の問題を引き起こしたりする可能性があります。

特に本番環境では、終了前に対象プロセスの役割と影響範囲を確認してください。

まとめ

Linuxのプロセスが応答しない場合は、まずpsやtopでプロセスの状態とリソース使用量を確認します。

終了できない場合も、すぐにkill -9を実行するのではなく、STAT欄やログを確認し、原因を切り分けることが大切です。

特にD状態のプロセスでは、ストレージやファイルシステムなど、カーネル内で待機している原因を調べる必要があります。

プロセスを終了させることだけを目的にせず、応答しなくなった原因を特定してから対処することが、安定したサーバー運用につながります。

Linuxで応答しないプロセスを確認するコマンドは何ですか？

ps auxやtopが基本です。PID、プロセスの状態、CPU・メモリ使用率などを確認し、必要に応じてログも調べます。

killとkill -9の違いは何ですか？

通常のkill PIDはSIGTERMを送信し、プロセスに終了を要求します。kill -9 PIDはSIGKILLを送信し、通常の終了処理を行わせずに強制終了させます。

kill -9を実行してもプロセスが消えないのはなぜですか？

プロセスがD状態など、カーネル内で割り込みできない待機状態にある可能性があります。プロセスの状態と、ストレージやファイルシステム関連のログを確認してください。

D状態とは何ですか？

D状態は、プロセスが通常、割り込みできないカーネル内の待機状態にあることを示します。ディスクI/Oなどの完了を待っている場合があり、待機の原因を調べる必要があります。

応答しないプロセスはすぐに再起動してもいいですか？

プロセスの役割や影響範囲によります。データベースや本番サービスでは、処理中のデータや接続への影響を確認してから対処してください。

類似投稿