「このサービス、本当に動いているのか?」という確認は、障害対応から定常監視まで頻繁に必要になります。現代の Linux 環境(systemd 標準)では確認手段が複数あり、目的に合った方法を選ぶことで作業時間を大幅に短縮できます。
まず結論:systemd サービスなら systemctl status が第一手
Apache、Nginx、MySQL、chronyd など、systemd に登録されたサービスの確認は systemctl status が最も効率的です。稼働状態・PID・直近のログを一度に確認できます。
# サービス名で状態確認(例:Apache)
$ systemctl status httpd
● httpd.service - The Apache HTTP Server
Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; preset: disabled)
Active: active (running) since Wed 2026-08-06 09:00:00 JST; 2h 15min ago
Main PID: 1234 (httpd)
Tasks: 213
Memory: 38.5M
CGroup: /system.slice/httpd.service
├─1234 /usr/sbin/httpd -DFOREGROUND
└─(ワーカープロセス)
Aug 06 09:00:00 hostname httpd[1234]: AH00558: httpd: Could not reliably determine...
ステータスの読み方は次のとおりです。
- active (running):正常稼働中
- inactive (dead):停止中(正常終了)
- failed:異常終了。出力下部のログに原因が表示される
- activating:起動処理中。しばらく待っても変わらなければ依存関係やタイムアウトを調査する
サービス名がわからない場合は systemctl list-units --type=service --state=running で稼働中サービスの一覧を取得できます。また、OS 再起動時に自動起動するかどうかは「Loaded:」行の enabled/disabled で確認します。enabled でも failed になっている場合はユニットファイルの設定や依存関係を疑います。
プロセス名で絞り込む:ps -C の使い方
systemd サービスとして登録されていないプロセス、あるいは起動スクリプトや手動実行で動いているプロセスを確認するには ps -C が有効です。コマンド名(プロセス名)を指定して絞り込みます。
# プロセス名で絞り込む(-l で詳細フィールドを表示)
$ ps -lC crond
F S UID PID PPID C PRI NI ADDR SZ WCHAN TTY TIME CMD
5 S 0 1124 1 0 80 0 - 1456 hr_run ? 00:00:00 crond
主要フィールドの意味は次のとおりです。
- S(状態):
S=スリープ(イベント待機中)、R=実行中、Z=ゾンビ(親プロセスが終了コードを回収していない) - PID:プロセス ID。シグナル送信や詳細調査で使用する
- PPID:親プロセスの PID。プロセスの親子関係を辿るときに参照する
- TTY が
?:端末を持たないバックグラウンドデーモンを示す
-C に指定するのはコマンド名(プロセス名)のみです。フルパス(/usr/sbin/crond)ではなく crond と指定します。また、カーネルはプロセス名を最大 15 文字に切り詰めるため、長い名前のプロセスを -C で検索する際は切り詰め後の文字列を使う必要があります。
PID を素早く取得する:pgrep と pidof
プロセス名から PID だけを取得したい場合は pgrep か pidof が最短です。スクリプト内での条件分岐や、kill の前の PID 確認にも使えます。
# pgrep:プロセス名(デフォルト部分一致)からPIDを取得
$ pgrep httpd
1234
1235
1236
# -x で完全一致に限定(意図しないプロセスを除外できる)
$ pgrep -x crond
1124
# pidof:完全一致でPIDを一行で取得
$ pidof crond
1124
# スクリプト内での稼働確認(終了コード 0=存在、1=不在)
$ pgrep -x crond > /dev/null && echo "running" || echo "not running"
running
pgrep はデフォルトで部分一致のため、-x で完全一致に絞るのが安全です。-u ユーザー名 でユーザーを限定する(例:pgrep -u www-data php-fpm)、-c でプロセス数を整数で返す、といった使い方も実務でよく登場します。
PID を指定してプロセスの詳細を確認する
PID が判明したら、ps -p で CPU 使用率・メモリ・起動からの経過時間を確認します。-o で出力フィールドを指定すると必要な情報だけを見やすく表示できます。
# PID を指定して詳細フィールドを表示
$ ps -p 1234 -o pid,ppid,stat,pcpu,pmem,etime,cmd
PID PPID STAT %CPU %MEM ELAPSED CMD
1234 1 Ss 0.1 0.3 02:15:30 /usr/sbin/httpd -DFOREGROUND
etime(起動からの経過時間)が異常に短い場合は、クラッシュと再起動が繰り返されているサインです。systemctl status で確認できないプロセスについては、起動引数を含むフルコマンドラインを /proc/PID/cmdline から直接読み取ることもできます。
# 起動引数を含むフルコマンドラインを確認(\0 区切りを空白に変換)
$ cat /proc/1234/cmdline | tr '\0' ' '
/usr/sbin/httpd -DFOREGROUND
実務でよく使う組み合わせパターン
現場での調査は複数のコマンドを組み合わせて使うことがほとんどです。代表的なパターンをまとめます。
サービスが停止していたら即起動する
$ systemctl is-active nginx || sudo systemctl start nginx
プロセス名から CPU・メモリ消費量を確認する
# pgrep でPIDを取得し、xargs で ps に渡す
$ pgrep mysqld | xargs ps -p -o pid,pcpu,pmem,etime,cmd
特定ユーザーで動いているプロセスをCPU使用率順に一覧する
$ ps -u www-data -o pid,stat,pcpu,pmem,cmd --sort=-%cpu | head -20
ある運用現場では、夜間バッチの重複起動を検知するために pgrep -c batch_job.sh でプロセス数を確認し、2 以上であればアラートを上げる仕組みをシェルスクリプトに組み込んでいました。ps 単体より pgrep のほうが終了コードで条件分岐しやすく、スクリプト向きです。
Docker・コンテナ環境での注意点:コンテナ内のプロセスはホスト側の ps 出力に現れることがあります(名前空間の設定によっては見えない場合もあります)。コンテナ内プロセスの確認は docker exec コンテナ名 ps aux や kubectl exec ポッド名 -- ps aux でコンテナ内から直接行うのが確実です。また、[kworker] や [migration] のように [ ] で囲まれたプロセス名はカーネルスレッドです。ps 出力に表示されますが、通常の kill では停止できません。
「コマンドは打てる。次は”現場で通用する型”を最短で身につけたい」——そんなあなたへ。
ネットの断片的なTipsをコピペするだけでは、体系的な運用スキルはなかなか積み上がりません。リナックスマスター.JPの無料メルマガ「リナマガ」では、現場で実際に使うLinuxサーバー運用の考え方を、順を追って実務目線でお届けしています。いま登録された方には、安全なサーバー構築の「型」をまとめた『Linuxサーバー構築入門マニュアル(図解60P)』を完全無料でプレゼント中です。
>> 図解60P『Linux入門マニュアル』を無料で受け取る
(メルマガ登録は10秒・いつでも解除OK)
※ 「独学の時間がもったいない」「プロから現場の技術を最短で学びたい」という本気の方には、2日で実務レベルが身につく初心者向けハンズオンセミナーもご用意しています。
