DAY 06: プロセス監視官

はじめに

ジュニアシステム管理者であるあなたに、月曜日の朝から緊急事態が発生しました。「LabEx」のメインアプリケーションサーバーが著しく低速化し、全ユーザーに影響が出ています。シニア管理者は緊急会議で手が離せません。システムを調査し、安定させるのはあなたの役目です。

これはあなたの実力を示す絶好の機会です。サーバーのコマンドラインに飛び込み、実行中のプロセスを検査して問題を診断し、リソースを過剰に消費している原因を特定して排除してください。また、重要なサービスが稼働し続けられるように調整します。このチャレンジを終える頃には、プレッシャーのかかる本番環境で Linux 環境を管理する、システム管理者にとって不可欠なスキルを証明できているはずです。

実行中のシステムプロセスのリスト表示

プロセス監視官としての最初のステップは、サーバー上で現在何が動いているのか、その全体像を把握することです。実行中のすべてのプロセスの静的なスナップショットを取得することで、調査を開始し、異常な点を見つけ出すことができます。

タスク

• 単一のコマンドを使用して、システムで実行されているすべてのプロセスの詳細なリストを生成してください。

要件

• 自分自身のプロセスだけでなく、すべてのユーザーのプロセスを表示すること。
• 出力形式はユーザー指向（user-oriented）とし、プロセスの所有ユーザー、CPU/メモリ使用率、およびプロセスを起動したフルコマンドなどの詳細を表示すること。

例

コマンドを実行すると、以下のような出力が表示されるはずです。

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.1 169848  9064 ?        Ss   08:30   0:02 /sbin/init
labex     1234  0.0  0.0   2324   564 pts/0    S+   08:35   0:00 bash /home/labex/project/resource_hog.sh
labex     1235  0.0  0.0   2324   564 ?        S    08:35   0:00 bash /home/labex/project/critical_service.sh
...

出力には、ユーザー、プロセス ID（PID）、CPU 使用率、メモリ使用率、および各プロセスを開始したコマンドの列を含む複数のプロセスが表示されます。

ヒント

• このタスクで最も一般的なコマンドは ps です。
• all（すべてのユーザー）、user-friendly（ユーザーに分かりやすい形式）、および texminal（端末）に紐付いていないプロセスも含めて表示するための ps コマンドのオプションを考えてみてください。

プロセスのリソース使用状況の監視

ps による静的なリストは良いスタートでしたが、サーバーの負荷は刻一刻と変化しています。どのプロセスが実際に速度低下を引き起こしているのかを確認するには、ライブで動的なビューが必要です。より強力な監視ツールを導入しましょう。

タスク

• システムプロセスとそのリソース使用状況をリアルタイムで監視するための、対話型のコマンドラインユーティリティを起動してください。
• 最も CPU を消費しているスクリプトの名前を特定してください。

要件

• システムプロセスの継続的に更新されるリアルタイムビューを提供するツールを使用すること。
• デフォルトでプロセスを CPU 使用率順にソートできるツールであること。
• 最もリソースを消費しているプロセスを特定したら、ツールを終了して次のステップに進むこと。

例

監視ツールを起動すると、以下のように自動的に更新される対話型画面が表示されます。

top - 09:15:30 up  1:45,  1 user,  load average: 1.50, 1.20, 0.85
Tasks: 105 total,   2 running, 103 sleeping,   0 stopped,   0 zombie
%Cpu(s): 45.0 us,  5.0 sy,  0.0 ni, 50.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
MiB Mem :   2048.0 total,    850.4 free,    950.2 used,    247.4 buff/cache
MiB Swap:      0.0 total,      0.0 free,      0.0 used,      0.0 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
 1234 labex     20   0   12884   1564   1320 R  95.0   0.1   2:15.30 bash /home/labex/project/resource_hog.sh
 1235 labex     20   0   12884   1564   1320 S   0.0   0.1   0:00.00 bash /home/labex/project/critical_service.sh
    1 root      20   0  169848   9064   6868 S   0.0   0.4   0:02.15 systemd
...

画面上部にはシステムの統計情報が表示され、その下に CPU 使用率順にソートされたプロセスのリストが表示されます。最も CPU を消費しているプロセスが一番上に表示されます。

ヒント

• この有名なコマンドは、Linux 界の「タスクマネージャー」としばしば呼ばれます。
• この対話型ツールは q キーを押すことで終了できます。

主要なプロセスの特定

トラブルメーカーである resource_hog.sh を見つけました。しかし、優れたシステム管理者は、むやみにプロセスを終了させたりはしません。あなたは critical_service.sh も実行されていることに気づきました。問題のプロセスに対処する前に、システムで実行されている主要なプロセスを特定し、理解しておく必要があります。

タスク

• critical_service.sh スクリプトのプロセス ID（PID）を見つけてください。
• その重要なサービスが正しく実行されていることを確認してください。

要件

• pgrep コマンドを使用して、critical_service.sh を実行しているプロセスの PID を検索すること。
• コマンドが実行中のプロセスを正常に見つけ出し、その PID を表示すること。

例

pgrep で PID を見つけると、以下のような出力が表示されます。

1235

この数字（この例では 1235）が、重要なサービスのプロセス ID です。

以下のコマンドを使用して、プロセスの詳細を確認できます。

ps -p 1235 -o pid,ppid,cmd

出力は以下のようになるはずです。

PID PPID CMD
1235 1 /bin/bash /home/labex/project/critical_service.sh

ヒント

• pgrep はプロセス名に基づいて PID を検索できます。
• フルコマンドラインに対してマッチングを行うには pgrep -f を使用します。

異常なプロセスの終了

主要なプロセスを特定できたので、サーバーを低速化させていた resource_hog.sh に対処しましょう。通常の運用状態に戻すために、このプロセスを終了させる必要があります。

タスク

• resource_hog.sh プロセスを終了させてください。

要件

• 事前に PID を調べる必要がなく、名前を指定してプロセスを終了できるコマンドを使用すること。
• pkill コマンドを使用して resource_hog.sh スクリプトを停止させること。

例

プロセスが終了したことを確認するために、終了後にプロセスリストをチェックします。終了前は以下のように表示されているかもしれません。

labex 1234 95.0 0.0 2324 564 pts/0 R+ 09:15 5:00 bash /home/labex/project/resource_hog.sh

正常に終了した後、同じ確認コマンドを実行すると、一致するプロセスが表示されない（grep コマンド自体のみが表示される）はずです。

labex 2345 0.0 0.0 2324 564 pts/0 S+ 09:20 0:00 grep resource_hog

ヒント

• pkill コマンドは、名前に基づいてプロセスに終了信号を送ります。
• コマンド実行後、ps aux | grep resource_hog を使用して、プロセスがもう実行されていないことを確認できます。

バックグラウンドプロセスの起動と管理

サーバーが再び安定しました！素晴らしい仕事です。一息つこうとしたその時、開発者からメッセージが届きました。長時間実行されるスクリプト data_processor.sh をサーバーで動かしてほしいとのことです。このスクリプトのためだけに、何時間もターミナルセッションを開き続けるわけにはいきません。ログアウトした後も実行が続くように、バックグラウンドで実行する必要があります。

タスク

• data_processor.sh スクリプトを、バックグラウンドで実行し、かつハングアップ（ターミナルを閉じても停止しない状態）しないように起動してください。

要件

• ~/project ディレクトリに移動して作業すること。
• nohup コマンドを使用してスクリプトを実行すること。
• & 演算子を使用してプロセスをバックグラウンドに送ること。
• スクリプトのすべての出力（標準出力と標準エラー出力の両方）を processor.log という名前のファイルにリダイレクトすること。

例

バックグラウンドでの起動に成功すると、以下のような出力が表示されます。

[1] 3456
nohup: ignoring input and appending output to 'processor.log'

[1] 3456 はジョブ番号とプロセス ID を示しています。ログファイルをチェックすることで、スクリプトが動作しているか確認できます。

cat processor.log

以下のような出力が表示されるかもしれません。

Starting data processing at Mon Sep 11 10:30:00 UTC 2025

また、プロセスがまだ実行中であることも確認できます。

ps aux | grep data_processor

これにより、バックグラウンドプロセスがアクティブであることが示されます。

ヒント

• nohup コマンドは "no hang up"（ハングアップさせない）の略です。
• コマンドの末尾にある & 記号は、シェルに対してバックグラウンドジョブとして実行するよう指示します。
• 標準出力は > で、標準エラー出力は 2>&1 でリダイレクトできます。

まとめ

おめでとうございます、管理者！サーバーの重大なパフォーマンス問題を無事に解決し、Linux プロセス管理の習熟度を証明しました。サーバーは安定し、重要なサービスが優先され、長時間実行されるタスクはバックグラウンドで着実に進んでいます。

このチャレンジを通じて、以下の能力を証明しました：

• ps を使用して実行中のすべてのプロセスをリストアップし、検査する。
• top を使用してシステムリソースをリアルタイムで監視する。
• pgrep を使用して重要なプロセスを特定する。
• pkill を使用して異常なプロセスを適切に終了させる。
• nohup と & を使用して、ログアウト後も持続するバックグラウンドジョブを実行・管理する。

これらは、システム管理者、DevOps、またはバックエンド開発のあらゆる役割において不可欠で価値の高い基本スキルです。あなたは潜在的な危機を、自身の専門知識を示す機会へと変えることができました。お疲れ様でした！