Linuxで稼働中の全プロセスを把握し不審な動きを素早く特定する手順

サーバーが急に重くなった、メモリ使用量が跳ね上がっている、身に覚えのないプロセスが動いているかもしれない――こうした場面で最初に打つべきコマンドが ps aux です。出力の読み方と絞り込み方を体系的に押さえておけば、問題の切り分けにかかる時間を大幅に短縮できます。

全プロセスを一覧表示する：まず打つ2つのコマンド

全プロセスを確認するには BSD スタイルと SysV スタイルの2系統があります。どちらも広く使われており、出力内容はほぼ同等です。

# BSD スタイル：ユーザー名・%CPU・%MEM が見やすい
ps aux

# SysV スタイル：親プロセスID（PPID）も確認したい場合に便利
ps -ef

出力例（Ubuntu 24.04 / Rocky Linux 9 で確認済み）：

USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root           1  0.0  0.1 167892 11360 ?        Ss   07:00   0:08 /sbin/init
systemd+     567  0.0  0.3  90412 12300 ?        Ssl  07:00   0:01 /lib/systemd/systemd-resolved
mysql       1234  0.1  5.2 1823456 212004 ?      Sl   07:00   2:14 /usr/sbin/mysqld
webapp      5678  0.3  2.1 512344  85312 ?       Sl   10:30   0:42 /usr/bin/python3 /opt/app/main.py
root        9999  0.0  0.0      0      0 ?       Z    11:00   0:00 [defunct]

現代の Linux では PID 1 が systemd（/sbin/init として表示されることもある）です。古い SysV 系で見られた mingetty は agetty に置き換わっており、カーネルスレッドは [kworker/0:1] のようにブラケットで囲まれて表示されます。

出力列の読み方とSTATステータスの解読

各列の意味を押さえると、異常の切り分けが格段に速くなります。

USER：プロセスを起動したユーザー名。root 所有のプロセスが想定より多い場合は権限設計の見直しが必要です。PID：プロセスID。kill コマンドの引数として使います。%CPU / %MEM：CPU・物理メモリの使用率。長時間 100% に張り付いているプロセスは要注意です。VSZ：仮想メモリサイズ（KB）。共有ライブラリ分も含まれるため、実消費の指標には不向きです。RSS：実際に物理メモリを占有しているサイズ（KB）。メモリ逼迫の判断には RSS を優先して見ます。TIME：累計 CPU 使用時間。数時間以上になっているプロセスは負荷の原因候補です。

STATステータスコードの読み方

STAT 列は1文字目の状態コードと追加フラグの組み合わせです。

R（Running）：実行中またはランキュー待機中。複数プロセスが R のまま続くなら CPU リソースの競合が起きています。S（Sleeping）：割り込み可能なスリープ。大半のプロセスはイベント待機のために S になっており正常です。D（Disk sleep）：割り込み不可のスリープ。通常は I/O 完了待ちですが、長時間続く場合はディスクや NFS の障害を疑います。T（Stopped）：シグナルによる一時停止、またはデバッガによるトレース中。意図しない T はジョブ制御の残骸かもしれません。Z（Zombie）：処理は終了しているが親プロセスが回収していない状態。少数なら問題ありませんが、大量発生は親プロセスのバグを示します。I（Idle kernel thread）：Linux カーネル 4.14 以降で登場したアイドル状態のカーネルスレッド。D との混同に注意してください。

2文字目以降の追加フラグも把握しておくと便利です。sはセッションリーダー、lはマルチスレッドプロセス、+はフォアグラウンドプロセスグループ、Nは低優先度（nice値が正）、<は高優先度（nice値が負）を示します。

CPUとメモリを大量消費しているプロセスを特定する

--sort オプションを使うと、消費の大きいプロセスをすぐに上位表示できます。

# CPU 使用率の高い順にトップ10を表示（ヘッダー行含め11行）
ps aux --sort=-%cpu | head -11

# メモリ（RSS）の多い順にトップ10を表示
ps aux --sort=-%mem | head -11

# 必要な列だけ絞って表示（PID・ユーザー・CPU・メモリ・コマンド名）
ps -eo pid,user,pcpu,pmem,comm --sort=-%cpu | head -11

ある運用現場では、深夜バッチの暴走を ps aux --sort=-%cpu | head -5 の一発で特定し、即座に kill して障害を最小化した事例があります。継続的な監視が目的であれば top や htop のほうが向いていますが、スクリプトや瞬間的なスナップショット取得には ps のほうが扱いやすいです。

目的のプロセスだけを絞り込む

全プロセスから特定のプロセスを探すには、grep との組み合わせか pgrep を使います。

# grep と組み合わせる定番パターン
# ただし grep プロセス自身が結果に含まれることがある
ps aux | grep nginx

# ブラケットで先頭1文字を囲むと grep 自身を除外できる
ps aux | grep [n]ginx

# pgrep でプロセス名から PID のみ取得（grep 汚染なし）
pgrep nginx

# pgrep -a でフルコマンドライン付き表示
pgrep -a nginx

# 特定ユーザーのプロセスだけ確認
ps -u webapp

pgrep は内部でプロセス名に対して正規表現マッチを行うため、grep の副作用を気にせず使えます。複数サービスが混在する環境では pgrep を積極的に使うと検索が安定します。

ゾンビプロセスと不審なプロセスの見分け方

STAT が Z のゾンビプロセスは kill しても消えません。ゾンビを回収する責任は親プロセスにあるため、親プロセスを再起動または終了させることで解消します。

# ゾンビプロセスの一覧と親プロセスID（PPID）を確認
ps -eo pid,ppid,stat,comm | awk '$3 ~ /Z/'

# 出力された PPID の親プロセスを確認
ps -ef | awk '$2 == "親PIDの数値"'

不審なプロセスを疑う際のチェックポイントは COMMAND 列です。実行ファイルのパスが /tmp や /dev/shm 配下にあるプロセスは、マルウェアが仕込まれた際の典型的なサインです。

# /tmp や /dev/shm から実行されているプロセスを探す
ps aux | awk '$11 ~ /\/tmp|\/dev\/shm/'

# プロセスIDから実行ファイルの実パスを確認（Linux 固有の /proc 経由）
ls -la /proc/対象PID/exe

COMMAND 列が (deleted) と表示されているプロセスにも注意が必要です。これは実行バイナリが削除済みであることを示しており、マルウェアがディスク上の痕跡を消した後も動き続けているケースに見られます。

systemctlとの使い分け：サービスの健全性確認はこちら

現代の Linux は systemd が標準です。ps がシステム全体の瞬間的なスナップショットを取るのに対し、systemctl はサービス単位の詳細な状態（起動失敗の原因、依存関係、ログの末尾）を把握するのに向いています。

# 稼働中のサービス一覧を確認
systemctl list-units --type=service --state=running

# 特定サービスの詳細確認（最近のログも表示される）
systemctl status nginx

# 起動に失敗しているサービスの一覧
systemctl --failed

「ps aux ではプロセスが存在しているのに挙動がおかしい」という場面では、systemctl status サービス名 でユニットの状態を確認するのが次のステップです。ps はプロセスの存在を教えてくれますが、サービスが正常に機能しているかどうかまでは教えてくれません。ログの詳細追跡には journalctl を組み合わせます。

# 特定サービスの最新ログを確認
journalctl -u nginx --since "1 hour ago"

# リアルタイムにログを流す
journalctl -u nginx -f

プロセスの存在確認には ps、サービスの健全性確認には systemctl、ログの追跡には journalctl と役割を分けて使うのが、現代の Linux サーバー運用における基本の構えです。