ソースコードビルド・ユーザ通知とLinuxリソース・死活監視【201試験 主題2.04】



Linuxシステムを長期にわたり安定運用するためには、パッケージ化されていない独自ソフトウェアの安全なビルド・導入、共有ライブラリの依存関係解決、確実なデータ保護（バックアップ）、メンテナンス時のユーザへの通知、そして障害の予兆を捉えるパフォーマンス・死活監視が欠かせません。LinuCレベル2（201試験）の主題2.04「システムの保守とリソース管理」では、これらの運用タスクを支えるコア技術が網羅的に問われます。

特に記述式問題（コマ問）では、./configure時のパス指定オプション、patchのストリップレベル指定（-p）、共有ライブラリのキャッシュ再生成（ldconfig）、rsyncのミラーリング構文、ログイン前後の通知ファイル（/etc/issue, /etc/motd）や同報通知（wall）、vmstatやsarの出力列の意味、そしてSNMPによる監視パラメータ（MIB, OID, snmpwalk）が頻出します。本記事では、AlmaLinux 9の実機検証ログに基づき、ビルド管理からユーザー通知、リソース監視・SNMPまでの手順を体系的に解説します。

1. ソースコードからのビルド手順とpatch適用#

RPMパッケージが提供されていない最新版ツールや、独自のコンパイルオプションを必要とするミドルウェアを導入する場合、ソースコードアーカイブ（tarball）からビルドして配置します。

1.1 configure・make・make install の3段階ビルドフロー#

C言語等で記述されたソフトウェアのビルドは、伝統的に以下の3ステップで実行されます。

1. 環境検査とMakefile生成（./configure）:
   実行環境にコンパイラや必要なヘッダファイル、共有ライブラリが存在するか検査し、その環境に特化したMakefileを生成するスクリプトです。配置先プレフィックス（--prefix=/usr/local/<app>）や機能有効化フラグ（--with-opensslなど）を指定します。
2. ソースコードのコンパイル（make）:
   Makefileに定義された依存ルールに従い、コンパイラ（gcc等）を呼び出してソースコード（.c）をオブジェクトファイル（.o）経由で実行可能バイナリへとコンパイル・リンクします。
3. バイナリの配置（make install）:
   コンパイルされたバイナリ、設定ファイル、マニュアルなどを、--prefixで指定したインストール先ディレクトリへコピー・配置します（通常root権限が必要）。

# アーカイブの展開
$ tar -xf app-1.2.0.tar.gz
$ cd app-1.2.0

# プレフィックスを指定して環境検査
$ ./configure --prefix=/opt/myapp

# コンパイル実行（並列ビルド -j4）
$ make -j4

# インストール実行
$ sudo make install

1.2 patchコマンドによるソース差分適用（-pオプションの strip レベル）#

バグ修正や機能追加の差分（パッチファイル）を既存ソースコードに適用するには、patchコマンドを使用します。差分はdiff -u（unified diff形式）で作成されているのが標準です。

試験において最も問われるのが、ディレクトリ階層を切り捨てる**-p（strip）オプション**の数値指定です。

--- a/src/main.c
+++ b/src/main.c
@@ -10,6 +10,7 @@

上記のようにパッチ内のパスがa/src/main.cとなっている場合、カレントディレクトリがソースツリーのルート（src/がある場所）であれば、先頭の「a/」という1階層分のプレフィックスを除去して適用する必要があります。このため、**-p1**を指定します。

# パッチの適用（先頭1階層を除去）
$ patch -p1 < bugfix.patch

# 適用したパッチを取り消す（ロールバック: -R オプション）
$ patch -R -p1 < bugfix.patch

2. 共有ライブラリの依存関係と管理（ldd と ldconfig）#

Linuxプログラムの多くは、単体で完結している静的バイナリではなく、実行時に共通部品（共有ライブラリ: .so）を動的にメモリへ読み込んでリンクする動的バイナリとして構成されています。

2.1 lddによる動的リンクライブラリの依存関係確認#

実行可能バイナリがどの共有ライブラリに依存し、それぞれがシステムのどのパスにマッピングされているかを調査するには、ldd（List Dynamic Dependencies）コマンドを使用します。

$ ldd /bin/ls
	linux-vdso.so.1 (0x00007ffd19d8a000)
	libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f6efabcc000)
	libcap.so.2 => /lib64/libcap.so.2 (0x00007f6efabc2000)
	libc.so.6 => /lib64/libc.so.6 (0x00007f6efa800000)
	libpcre2-8.so.0 => /lib64/libpcre2-8.so.0 (0x00007f6efab26000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f6efac00000)

もし必要なライブラリが見つからない場合、not foundと表示され、プログラムの実行は失敗します。

2.2 /etc/ld.so.conf と ldconfig によるライブラリキャッシュ更新#

動的リンカ（ld.so）は、プログラム起動時に毎回ファイルシステム全域を検索するのではなく、高速化のために作成されたバイナリキャッシュファイル/etc/ld.so.cacheを参照します。

標準外のパス（/usr/local/libや/opt/myapp/libなど）に新しい共有ライブラリを配置した場合、以下の手順でシステムに認識させます。

1. 設定ファイル/etc/ld.so.conf、または/etc/ld.so.conf.d/*.confに、ライブラリが格納されたディレクトリパスを追記します。
2. root権限でldconfigコマンドを実行し、キャッシュ（/etc/ld.so.cache）を再構築します。

# 設定ファイルにパスを追加
$ echo "/opt/myapp/lib" | sudo tee /etc/ld.so.conf.d/myapp.conf

# キャッシュを再生成
$ sudo ldconfig

# キャッシュに登録されたライブラリ一覧を確認（-p オプション）
$ ldconfig -p | grep libpcre2
	libpcre2-posix.so.3 (libc6,x86-64) => /lib64/libpcre2-posix.so.3
	libpcre2-8.so.0 (libc6,x86-64) => /lib64/libpcre2-8.so.0

2.3 環境変数 LD_LIBRARY_PATH の役割と実務での注意点#

システム全体の設定を変更せず、特定のシェルセッションや特定プロセスでのみ一時的にライブラリ検索パスを追加したい場合は、環境変数LD_LIBRARY_PATHを使用します（例: export LD_LIBRARY_PATH=/opt/myapp/lib:$LD_LIBRARY_PATH）。ただし、予期せぬバージョンのライブラリが優先リンクされる危険があるため、恒久的な設定には/etc/ld.so.confを利用するのがベストプラクティスです。

3. バックアップとアーカイブ運用（tar, rsync, dd）#

Linuxサーバーの運用において、設定ファイルやデータベースのバックアップはデータ損失を防ぐ最後の防壁です。用途に応じて最適なツールを選定します。

3.1 tarコマンドによる圧縮アーカイブ作成と展開（-z, -j, -J, -p）#

複数のファイルやディレクトリを1つのアーカイブファイルにまとめるのがtar（Tape Archive）です。各圧縮形式に応じたオプションの組み合わせが試験で必須となります。

# パーミッションを保持（-p）して /etc を gzip 圧縮アーカイブ（-czf）
$ sudo tar -cpzf /backup/etc-backup.tar.gz /etc

# アーカイブ内容の確認（-t）
$ tar -tzf /backup/etc-backup.tar.gz | head -n 5

# 指定ディレクトリへの展開（-C オプション）
$ sudo tar -xpf /backup/etc-backup.tar.gz -C /restore/

3.2 rsyncによる高効率なリモート差分同期（-a, -v, -z, –delete）#

ファイル単位の差分のみを効率的に転送し、バックアップサーバーと同期するツールがrsyncです。

4. メンテナンス告知とユーザへの通知【主題2.04.3】#

システムの定期メンテナンスや緊急シャットダウンを行う際、ログイン中またはこれからログインしようとするユーザーに対して適切にメッセージを通知することは、サーバー管理者の必須業務です。Linuxにはログイン前・ログイン後・稼働中の3つのフェーズに応じた通知機構が用意されています。

4.1 ログイン前後の静的通知ファイル（/etc/issue, /etc/issue.net, /etc/motd）#

テキストエディタでメッセージを記述しておくだけで、ユーザーの接続タイミングに応じて画面に表示される静的設定ファイルです。

4.2 ログイン中ユーザーへの即時同報通知（wall）#

サーバーに現在ログインしているすべてのユーザーの端末画面（ptsやtty）に対して、緊急の告知メッセージを一斉送信（ブロードキャスト）するコマンドが wall（Write to ALL）です。

# 引数に直接メッセージ文字列を渡して一斉送信
[user01@linuc-node01 ~]$ wall "Emergency: System maintenance will start in 10 minutes. Please save your work."

# 作成済みのテキストファイルの内容を一斉送信（リダイレクト）
[user01@linuc-node01 ~]$ wall < /etc/maintenance_notice.txt

# 各ユーザーの端末画面に以下のように即座に割り込み表示される
Broadcast message from user01@linuc-node01 (pts/0) (Tue Sep  8 01:15:00 2026):

Emergency: System maintenance will start in 10 minutes. Please save your work.

4.3 シャットダウン予約とキャンセル（shutdown）#

メンテナンス時にシステムを停止または再起動する際は、shutdown コマンドを使用します。時刻指定とともにメッセージを記述することで、ログイン中の全ユーザーへ自動的に wall と同様の事前通知が定期的に送信されます。

# 15分後にシステムをシャットダウン（停止）し、理由をユーザーへ通知
[root@linuc-node01 ~]# shutdown -h +15 "System will be shut down for memory upgrade."

# 指定時刻（例: 23:30）に再起動（-r）を予約
[root@linuc-node01 ~]# shutdown -r 23:30 "Scheduled reboot for kernel update."

# 予約中のシャットダウンを取り消し（キャンセル: -c）し、取り消しメッセージを通知
[root@linuc-node01 ~]# shutdown -c "Maintenance postponed to tomorrow."

5. システムリソースの動的監視（vmstat, iostat, free, uptime）【主題2.04.4】#

サーバーの応答遅延や障害が発生した際、どのハードウェアリソースがボトルネックとなっているかを瞬時に特定するための標準ツール群を使い分けます。

5.1 ロードアベレージとCPUボトルネックの把握（uptime, vmstatのr列・b列）#

システム全体の負荷状況を把握する基礎がuptimeコマンドで表示されるロードアベレージ（Load Average）です。

$ uptime
 00:15:15 up 12:43,  0 users,  load average: 0.00, 0.00, 0.00

表示される3つの数値は、それぞれ過去1分間、5分間、15分間における「CPU実行待ち、またはディスクI/O完了待ちのプロセス数の平均」です。この値がシステムの**CPU論理コア数**を超えている場合、処理待ち行列が発生していると判断します。

さらにプロセスの状態を詳細に分解するのがvmstatです。

$ vmstat 1 2
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 1  0      0 3141852   7492 353768    0    0    12    14   15   27  0  0 100  0  0
 0  0      0 3141852   7492 353840    0    0     0     0  120  129  0  0 100  0  0

試験対策として、以下の列の意味を正確に記憶しておく必要があります。

5.2 メモリとスワップ消費の分析（free）#

メモリ消費の確認にはfree -hを使用します。

$ free -h
               total        used        free      shared  buff/cache   available
Mem:           3.6Gi       462Mi       3.0Gi        11Mi       352Mi       3.1Gi
Swap:          3.9Gi          0B       3.9Gi

Linuxカーネルは、空いているメモリを自動的にディスクキャッシュ（buff/cache）として利用します。したがって、free列の数値が少なくても問題ありません。アプリケーションが新規に確保できる実際の残余メモリは**available列**の数値で判断します。

5.3 ディスクI/O負荷の計測（iostat）#

ストレージデバイスごとの詳細なI/O統計を取得するには、sysstatパッケージに含まれるiostatを使用します（例: iostat -xz 1）。

• %util: デバイスにI/O要求が発行されていた時間の割合（稼働率）。100%に近い場合、ストレージデバイスの処理能力が飽和しています。
• await: デバイスに発行されたI/O要求が完了するまでの平均時間（ミリ秒、キュー待ち時間＋サービス時間）。数値の急増はストレージの遅延悪化を示します。

6. 性能統計の蓄積と解析（sysstat / sar）【主題2.04.4】#

リアルタイムの監視だけでなく、「昨日の夜間にサーバーが重かった原因は何か」といった事後調査を行うには、定期的にメトリクスを自動収集・蓄積するsysstatとsarコマンドを活用します。

6.1 sysstatのデータ収集の仕組みと /var/log/sa/#

sysstatサービスを起動すると、systemdタイマー（またはcron）経由で定期的に収集スクリプト（sa1）が実行され、システム統計データが/var/log/sa/配下に日次バイナリファイル（saDD、DDは日付2桁）として自動記録されます。また、1日1回sa2スクリプトによって日次テキストレポート（sarDD）が生成されます。

6.2 sarコマンドによる過去リソース使用率のグラフ化・レポート#

sar（System Activity Reporter）コマンドは、引数で取得対象のメトリクスを指定し、過去のログファイル（-f）から特定時間帯の統計を抽出・分析します。

# 当日の CPU 使用率を表示
$ sar -u

# 当月の15日のログファイルからメモリ使用率を表示（-f オプション）
$ sar -r -f /var/log/sa/sa15

# 特定時間帯（10:00から12:00まで）に絞り込んで表示（-s, -e オプション）
$ sar -u -s 10:00:00 -e 12:00:00

7. 死活監視・リソース監視ツールとSNMP【主題2.04.5】#

サーバー単体での vmstat や sar による監視にとどまらず、多数の物理サーバー・仮想マシン・ネットワーク機器で構成されるエンタープライズシステムでは、専用の監視ソフトウェアや標準ネットワーク管理プロトコルを用いた一元的な死活監視・性能監視が不可欠です。

7.1 統合監視ソフトウェアの代表例（Nagios と Zabbix）#

LinuC試験では、オープンソースの代表的な統合監視ソフトウェアの特徴と役割が出題されます。

7.2 SNMP（Simple Network Management Protocol）による監視の仕組み#

SNMP（Simple Network Management Protocol） は、ベンダーやOS（Linux、Windows、ルーター、スイッチ）を問わず、ネットワークに接続された機器の稼働状態を共通規格で監視・制御するための業界標準プロトコル（UDP使用）です。

SNMPの基本構成：マネージャーとエージェント

• SNMPマネージャー（Manager）: 監視サーバー側。エージェントへ定期的に問い合わせて情報を収集したり、エージェントからの緊急通知を受信します。
• SNMPエージェント（Agent）: 監視対象機器側で稼働するデーモン（Linuxでは snmpd）。自ホストのCPU使用率、インターフェース通信量、ディスク残量などの情報を保持し、マネージャーへ応答します。

ポーリング（取得）とSNMPトラップ（通知）の通信ポート

• ポーリング方式（要求・応答）: マネージャーからエージェントの UDP 161番ポート へ GetRequest や GetNextRequest を送信し、状態値を取得（GetResponse）します。
• SNMPトラップ方式（自発通知）: エージェント側で機器障害や閾値超過などのイベントを検知した際、マネージャーの UDP 162番ポート へ向けて自発的に警報メッセージ（Trap または InformRequest）を送信します。

7.3 MIB（管理情報ベース）とOID（オブジェクト識別子）#

SNMPでやり取りされる管理データ項目は、階層的なツリー構造で定義されています。このツリー構造の仕様を MIB（Management Information Base）、各項目を一意に特定する数字の並びを OID（Object Identifier） と呼びます。

• OIDの表記例: .1.3.6.1.2.1.1.1.0（インターネット標準MIBの sysDescr を指し、OSの種類やバージョン情報を返す）
• 標準MIBと拡張MIB: RFCで共通定義された標準MIB（MIB-II等）に加え、各ハードウェアベンダーが独自定義するプライベートMIB（エンタープライズMIB）が存在します。

7.4 SNMPのバージョンとセキュリティ（v2c vs v3）#

7.5 LinuxにおけるSNMPクライアントコマンド（snmpwalk, snmpget）#

Linux環境でSNMPエージェントから情報を取得するには、net-snmp-utils パッケージに含まれる snmpget や snmpwalk コマンドを使用します。

# SNMPv2c、コミュニティ名「public」で、自ホストの system ツリー配下を一括再帰取得
[user01@linuc-node01 ~]$ snmpwalk -v 2c -c public localhost system
SNMPv2-MIB::sysDescr.0 = STRING: Linux linuc-node01 5.14.0-570.el9.x86_64 #1 SMP PREEMPT_DYNAMIC
SNMPv2-MIB::sysObjectID.0 = OID: NET-SNMP-MIB::netSnmpAgentOIDs.10
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (123456) 0:20:34.56
SNMPv2-MIB::sysContact.0 = STRING: Root <root@localhost>
SNMPv2-MIB::sysName.0 = STRING: linuc-node01
SNMPv2-MIB::sysLocation.0 = STRING: Unknown

# 単一のOID（sysUpTimeInstance）のみをピンポイント取得
[user01@linuc-node01 ~]$ snmpget -v 2c -c public localhost DISMAN-EVENT-MIB::sysUpTimeInstance
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (124000) 0:20:40.00

8. LinuC 201試験（主題2.04）重要ポイント総整理#

主題2.04で頻出するコマンド、オプション、設定ファイルを整理します。

8.1 記述式（コマ問）頻出コマンド・オプション一覧#

8.2 混同しやすい監視指標とコマンド引数#

• vmstat の r列 と b列:
  • r ➔ Runnable（CPU実行待ちプロセス数）。CPUコア数との比較が重要。
  • b ➔ Blocked（I/O完了待ちなどでスリープしているプロセス数）。ストレージネックの特定に直結。
• patch の -p0 と -p1:
  • 差分ファイル内のパス記述（a/dir/file）と、現在実行しているカレントディレクトリの階層関係を正確に読み取り、除去するスラッシュの数を指定する。
• 共有ライブラリの設定パス:
  • 設定ファイルは /etc/ld.so.conf（および /etc/ld.so.conf.d/*.conf）。
  • 生成されるバイナリキャッシュは /etc/ld.so.cache。
• ログイン通知ファイルの棲み分け:
  • /etc/issue: ログイン前・ローカルコンソール（tty）用
  • /etc/issue.net: ログイン前・ネットワーク（SSH等）用（Bannerディレクティブで有効化）
  • /etc/motd: ログイン成功直後・全ユーザー用
• SNMPのポート番号と監視方式:
  • マネージャーからの情報取得（ポーリング）: UDP 161
  • エージェントからの自発的障害通知（SNMPトラップ）: UDP 162

9. まとめ：リソース監視・システム保守が安定運用の土台を作る#

Linuxサーバーの信頼性は、必要なソフトウェアを適切な依存関係のもとで導入し、日常的にリソースメトリクスのベースラインを把握しておくことで担保されます。

CPU・メモリ・ディスクI/O・ネットワークの各ボトルネックがどの指標（vmstatのrやsi/so、iostatの%util等）に現れるかを体得しておくことは、試験合格のみならず実務での障害一次切り分けにおいて最も強力な武器となります。

次回（第6回）は、運用自動化の要となる「構成管理ツールAnsible入門とPlaybookによる自動化」（インベントリ設計、YAML記法の基礎、主要モジュール、冪等性の確保）を取り上げます。

リンク