第14章: トラブルシューティングと問題解決
14.1 トラブルシューティング概要
14.1.1 トラブルシューティングの重要性
システム運用におけるトラブルシューティングは、問題をただ「解決」するだけではなく、同様の障害を未然に防ぎ、AlmaLinux 9環境の安定性・信頼性を維持・向上させるための重要なプロセスです。仮に障害対応を後回しにすると、業務停止やデータ損失といった重大インシデントに発展するリスクが高まります。
特にAlmaLinux 9はRHEL互換のエンタープライズ向けディストリビューションであり、長期サポートやセキュリティ設定（SELinuxやファイアウォール管理など）が強力な反面、設定ミスやパッケージ更新（dnf）時の依存関係エラーなど、初心者～中級者が遭遇しやすいトラブルも少なくありません。トラブルシューティングのスキルを身につけることで、迅速な復旧だけでなく、原因分析に基づいた恒久対策の立案・実装が可能になります。
💡 補足：トラブルシューティングは単なる問題解決ではなく、システムの継続的な改善サイクル（PDCAサイクル）の「Check」「Act」に相当します。問題を再発防止策としてフィードバックすることで、運用品質を高められます。
14.1.2 対象と範囲（AlmaLinux 9 環境で想定される障害）
本ガイドでは、以下に示すようなAlmaLinux 9環境で頻出するトラブルを対象とし、基本的な切り分け手順と対策を解説します。
- パッケージ管理エラー：
dnf updateや依存関係（dependency）問題 - サービス起動失敗：
systemctl start時のエラーやユニットファイルの文法ミス - SELinux拒否：ポリシー設定やコンテキスト不一致によるアクセス制御エラー
- ネットワーク障害：疎通確認（ping/traceroute）、ルーティング設定不備
- ストレージ・ファイルシステム障害：LVM、XFS、EXT4の不整合や容量不足
- ブートプロセス異常：GRUB設定エラー、initramfsの破損、UEFI問題
- ハードウェア障害：ディスク故障、メモリエラー、NICの故障
❗ 注意：本ガイドは標準的なAlmaLinux 9のインストール・設定を前提としています。カスタムカーネルや特殊なハードウェア構成の場合、手順や対策が異なることがあります。
14.2 トラブルシューティングの基本フロー
14.2.1 問題の把握と再現性確認
まず最初に行うのは、発生している問題を正確に把握し、再現性を確認することです。目に見えるエラーや障害の症状（エラーメッセージ、サービス停止、通信断など）をログやコンソール出力から取得し、以下の手順で整理します。
- ✅ 事象記録：障害発生時刻、影響範囲、再現手順を時系列でメモする
- ✅ 再現テスト：同じ操作環境（同一サーバー、同一コマンド）で再度障害が発生するか確認
- ✅ バリエーション確認：他のサーバーや異なるユーザー権限・ネットワーク環境でも再現するか試行
再現性が確認できない場合、問題の切り分けは難航します。必ず再現手順を明文化し、担当者間で共有しましょう。
14.2.2 ログの参照と関係者ヒアリング
問題の手がかりはログファイルに最も多く含まれます。以下のログを優先的に確認し、エラーコードや警告メッセージをキーワード検索で抽出します。
journalctl -xe：直近のsystemdサービスやカーネルログ/var/log/messages：システム全般のログ（rsyslog 経由）/var/log/dnf.log：パッケージ管理エラー履歴- アプリケーション固有ログ：
/var/log/httpd/、/var/log/nginx/など
また、問題発生時に操作した管理者やアプリケーション開発者へのヒアリングを並行して行い、どのような変更（設定変更、パッケージ更新、デプロイなど）がトリガーになったかを洗い出します。
14.2.3 切り分けと応急対応／恒久対策
ログとヒアリング情報をもとに、システムを構成する要素（ネットワーク、ファイルシステム、SELinux、サービスなど）ごとに問題を切り分けます。以下の手順で進めると効率的です。
- ✅ 影響範囲の特定：単一プロセスか複数プロセスか、特定ノードかクラスタ全体かを把握
- ✅ 仮説立案：「SELinuxポリシーが原因か」「ディスクI/O障害か」など、可能性をリストアップ
- ✅ 仮説検証：一つずつ仮説を潰す形で、テストコマンドや設定変更を実施
- ✅ 応急対応：業務継続に必要最低限の回避策を適用（例：一時的にSELinuxを許可モードへ切り替え）
- ✅ 恒久対策：根本原因を究明し、設定修正やパッケージ更新、ドキュメント整備など恒久対応を実施
- ✅ 検証・レビュー：テスト環境で再度同様の負荷・操作を行い、再発しないことを確認
- ✅ ドキュメント化：手順・原因・対策をナレッジベースや運用マニュアルに記録
次に、トラブルシューティングの効率をさらに高める自動化スクリプト例として、システム情報と主要ログを一括収集するスクリプトを紹介します。
実行ユーザー：root または sudo 権限を持つユーザー
目的：トラブルシューティングに必要なシステム情報を自動収集し、分析を効率化すること
期待される結果：/tmp/troubleshoot-$(hostname).tar.gz に主要ログとシステム情報が格納される
#!/bin/bash
# システム名を取得してファイル名に使用
HOSTNAME="$(hostname)" # ホスト名を取得
# 一時ディレクトリを作成
TMPDIR="$(mktemp -d)" # ログ格納用の一時ディレクトリ作成
# journalctl の詳細ログを保存
journalctl -xe > "${TMPDIR}/journal.log" # systemd/カーネルの詳細ログ
# dnf transaction history を保存
dnf history > "${TMPDIR}/dnf-history.log" # パッケージ管理履歴の取得
# メモリ・CPU 情報を保存
free -h > "${TMPDIR}/memory.log" # メモリ使用状況を取得
lscpu > "${TMPDIR}/cpu.log" # CPU 情報を取得
# ディスク情報を保存
df -h > "${TMPDIR}/disk.log" # ディスク使用状況を取得
lsblk > "${TMPDIR}/lsblk.log" # ブロックデバイス情報を取得
# ネットワーク情報を保存
ip addr show > "${TMPDIR}/ip_addr.log" # ネットワークインターフェース情報
# 収集データを圧縮
tar -czf "/tmp/troubleshoot-${HOSTNAME}.tar.gz" -C "${TMPDIR}" . # データを圧縮
# 一時ディレクトリを削除
rm -rf "${TMPDIR}" # 作業用一時ディレクトリのクリーンアップ
# 完了メッセージを出力
echo "Troubleshoot data collected in /tmp/troubleshoot-${HOSTNAME}.tar.gz" # 完了通知
14.3 ログファイル解析
14.3.1 journalctl の高度な活用
systemd ジャーナルに格納されたログを効率よく参照・絞り込むことで、問題の発見と原因分析を高速化できます。以下のポイントを押さえましょう。
- ブートごとの絞り込み：
journalctl -bで現在の起動以降のログを表示 - 優先度フィルター：
-p errでエラー以上（error, crit, alert, emerg）のメッセージのみ抽出 - サービス単位：
-u httpd.serviceで特定ユニットのログを確認 - 時間指定：
--since "2025-05-10 12:00"や--until "2025-05-10 15:00"で範囲指定
これらを組み合わせることで、例えば「昨日12時以降に発生した httpd のエラー」を1行で取得できます。
# 昨日2025-05-10 12:00以降のhttpdエラーを表示
journalctl -u httpd.service -p err --since "2025-05-10 12:00" # 指定サービス・エラー・開始時刻で絞り込み
# 現在のブート内でクリティカル以上のメッセージをリアルタイム表示
journalctl -b -p crit -f # ブート単位・クリティカル以上・フォロー表示
# JSON形式で出力し、他ツールで解析しやすくする
journalctl -b -o json-pretty # ブート単位・JSON整形形式で出力
journalctl はファイルではなくバイナリ形式のジャーナルを参照するため、大量ログでも高速かつ安全に検索できます。既定では /var/log/journal に保存され、永続化設定がなければ /run/log/journal に保持されます。
14.3.2 /var/log ディレクトリと dnf ログ
従来の syslog (rsyslog) によって /var/log 以下に出力されるテキストログも重要です。以下の主要ログファイルを把握しましょう。
/var/log/messages：システム全般の情報・警告・エラー（カーネルやrsyslog経由）/var/log/secure：認証・sudo 操作の記録/var/log/boot.log：ブート時の systemd および初期化スクリプト出力/var/log/dnf.log：dnf の実行履歴とトランザクション結果/var/log/dnf.rpm.log：パッケージインストール・アンインストール詳細
例えば、dnf 関連の障害では /var/log/dnf.log を調べることで、具体的にどの依存関係が失敗したかを特定できます。
# /var/log 以下のログファイルサイズを一覧表示
ls -lh /var/log/*.log # ログファイルのサイズ確認
# 最近のdnfエラーを抽出
grep -i "error" /var/log/dnf.log # 大文字小文字無視で「error」を検索
# dnfのトランザクション履歴一覧
dnf history list # トランザクションID, 日時, コマンドを表示
# 特定トランザクションの詳細を確認
dnf history info 42 # ID 42 のトランザクション詳細を表示
/var/log のログはプレーンテキストなので、grep 等の伝統的手法と併用しやすい点がメリットです。
14.3.3 grep／zgrep によるキーワード検索
テキストログや圧縮済みログを対象に、grep 系コマンドでキーワード検索を行う基本テクニックとスクリプト例を紹介します。
- 基本検索：
grep -i "fail" /var/log/messages（大文字小文字を無視） - 前後行の表示：
grep -n -C 3 "timeout" /var/log/messages（該当行前後3行を出力） - 圧縮ログ検索：
zgrep -i "segfault" /var/log/messages.*.gz（gz 圧縮ファイルを検索） - 複数ファイル一括検索：
grep -R --include="*.log" "error" /var/log（再帰検索）
# 大文字小文字無視でログ内の「fail」を検索
grep -i "fail" /var/log/messages # 「fail」を含む行を抽出
# 該当行番号と前後3行を表示
grep -n -C 3 "timeout" /var/log/messages # コンテキスト行と行番号付きで出力
# 圧縮済みログから「segfault」を検索
zgrep -i "segfault" /var/log/messages.*.gz # gzファイル内も自動的に展開して検索
# /var/log 以下の*.logを再帰検索
grep -R --include="*.log" "error" /var/log # ログディレクトリ全体を検索
さらに、定型的にエラー発生回数を集計する簡易スクリプト例を示します。
実行ユーザー：root または sudo 権限ユーザー
目的：ブート内のエラー発生数をユニット別に集計し、傾向を把握する
期待される結果：各ユニット名とエラー件数の降順一覧が標準出力に表示される
#!/bin/bash
# 現在のブートで発生した ERROR レベルのログを取得しユニット名で集計
journalctl -b -p err -o short-precise | \ # ブート内エラーを短い精度形式で取得
awk '{print $5}' | sort | uniq -c | sort -nr # 5列目(ユニット名)をカウントし降順ソート
14.4 ネットワーク関連問題の切り分け
AlmaLinux9環境でネットワーク障害はサービス停止や遅延を引き起こし、システム全体の可用性に直結します。本節では、レイヤー1〜3を中心に基本的な切り分け手順を「疎通確認」「ソケット・ルーティング確認」「パケットキャプチャ」の3ステップで詳述します。
14.4.1 ping／traceroute による疎通確認
ネットワークの最初の入り口はICMPエコーとパス追跡です。pingで到達性と遅延を測定し、tracerouteで経路上の各ホップを可視化します。これにより、どのセグメントで障害が起きているかを大まかに特定できます。
- ■ ping: 指定ホストへの到達性とラウンドトリップタイム(RTT)を測定します
- ■ traceroute: パケットが目的地に到達するまでの経路と各ホップの遅延を表示します
# サーバー192.168.1.100への疎通確認を4回実行
ping -c 4 192.168.1.100 # -c 4で4回だけICMPエコーを送信しRTTを測定
# ドメイン名での疎通確認とホスト名解決確認
ping -c 4 example.com # DNS解決後に指定ホストへの電文送信をテスト
# ホップごとの経路と遅延を数値のみで表示
traceroute -n example.com # -nでIPアドレスのみ表示、DNS逆引きを省略
# UDPベースのtraceroute実行例（デフォルトはUDPパケット）
traceroute example.com # 標準的なUDPパケットによる経路追跡
traceroute -IでICMP、traceroute -TでTCP SYNパケットを利用した追跡も可能です。用途に応じて使い分けましょう。14.4.2 ss と ip コマンドでソケット・ルーティング確認
次に、ローカルホスト上のソケット状態とルーティング設定を確認します。ssはnetstatの後継として高性能化され、ipコマンドはifconfigより豊富なサブコマンドを提供します。
- ■ ss: TCP/UDPソケットの状態、ポート一覧、プロセス紐付きを確認します
- ■ ip addr/route: インターフェースのIP情報とルーティングテーブルを参照します
# TCP,UDPの待ち受けソケット一覧とプロセスPID:プログラム名表示
ss -tulnp # -t:TCP, -u:UDP, -l:LISTEN, -n:数値, -p:プロセス情報
# 全インターフェースのIPアドレス表示
ip -4 addr show # -4でIPv4のみ、インターフェースごとのIPとステータスを表示
# IPv4ルーティングテーブルを一覧表示
ip -4 route show # ルーター経路とデフォルトゲートウェイ設定を取得
# 全インターフェースの統計情報
ip -s link show # -sで統計情報（受信/送信パケット数、エラー数）を併せて表示
14.4.3 tcpdump によるパケットキャプチャと解析
詳細分析にはtcpdumpで実際のパケットをキャプチャし、問題再現時のトラフィックを調査します。フィルタリングで対象を絞り込み、Wiresharkなどで後段解析するのが一般的です。
- ■ tcpdump: ネットワークインターフェースを通過するパケットをキャプチャできます
- ■ -nn: ホスト名/サービス名の解決を行わず、数値形式で表示
- ■ -c: キャプチャするパケット数を制限
- ■ -w: pcap形式でファイル出力
# eth0インターフェースの最初の100パケットを数値形式でキャプチャ
tcpdump -i eth0 -nn -c 100 -w /tmp/capture_eth0.pcap # -iでインターフェース指定
# port 80のTCPパケットのみリアルタイムで表示
tcpdump -i eth0 -nn tcp port 80 -c 50 # HTTPポートのトラフィックを50パケット取得
# ICMPパケットの概要表示
tcpdump -i eth0 icmp # ICMPのみをフィルタリングし可視化
# ファイルから読み込み
tcpdump -nn -r /tmp/capture_eth0.pcap # 保存したpcapファイルを解析モードで読み込み
最後に、これらのコマンドを組み合わせて一括収集する自動診断スクリプト例を示します。
実行ユーザー：root または sudo 権限ユーザー
目的：ネットワーク関連情報（インターフェース／ルート／ソケット／疎通／経路／パケット）を自動で収集し、分析を効率化する
期待される結果：/tmp/netdiag_タイムスタンプ.tar.gz に全診断ログとキャプチャファイルが格納される
#!/bin/bash
TIMESTAMP="$(date +%Y%m%d_%H%M%S)" # 現在日時をタイムスタンプ形式で取得
OUTDIR="/tmp/netdiag_${TIMESTAMP}" # 出力ディレクトリを定義
mkdir -p "${OUTDIR}" # 出力ディレクトリを作成
ip -4 addr show > "${OUTDIR}/ip_addr.log" # IPv4アドレス情報を保存
ip -4 route show > "${OUTDIR}/ip_route.log" # IPv4ルーティングテーブルを保存
ss -tulnp > "${OUTDIR}/ss_listening.log" # 待ち受けソケット一覧を保存
ping -c 4 8.8.8.8 > "${OUTDIR}/ping_google.log" # Google DNSへの疎通結果を取得
traceroute -n 8.8.8.8 > "${OUTDIR}/traceroute_google.log" # Google DNSへの経路情報を取得
tcpdump -i eth0 -nn -c 100 -w "${OUTDIR}/capture.pcap" # 最初の100パケットをキャプチャ
tar -czf "/tmp/netdiag_${TIMESTAMP}.tar.gz" -C "${OUTDIR}" . # 収集結果を圧縮
echo "Network diagnostic data saved to /tmp/netdiag_${TIMESTAMP}.tar.gz" # 完了メッセージを表示
ip link showで正しいデバイス名を確認してから実行してください。14.5 SELinux 関連のトラブルシューティング
14.5.1 AVC 拒否ログの解析方法
SELinux がアクセスを拒否した際には、AVC（Access Vector Cache）メッセージがログに記録されます。主に /var/log/audit/audit.log と /var/log/messages、または journald に残るため、これらを検索して原因を特定します。
- ■ ausearch: audit サブシステムのログ検索
- ■ grep: プレーンテキストログから AVC キーワード抽出
以下の手順で AVC メッセージを抽出し、いつどのプロセスが何を試みて拒否されたかを把握します。
実行ユーザー：root または sudo 権限ユーザー
目的：AVC メッセージを抽出して拒否原因を特定する
期待される結果：対象の AVC メッセージと詳細情報が表示され、scontext/tcontext などが確認できる
#!/bin/bash
# 本日発生した AVC メッセージを検索
ausearch -m AVC,USER_AVC -ts today # -m で AVC と USER_AVC、-ts today で本日分を抽出
# audit.log を直接 grep で検索
grep avc: /var/log/audit/audit.log # 「avc:」を含む行を抽出して拒否ログを確認
上記で抽出した AVC メッセージから、scontext（送信側コンテキスト）や tcontext（対象側コンテキスト）、tclass（リソース種別）を確認し、次節の setroubleshoot や sealert で詳細を調査します。
14.5.2 setroubleshoot を使った原因特定と対処
setroubleshootd デーモンは、AVC 拒否ログを解析して人間向けのレポートを生成します。journalctl -t setroubleshoot や sealert コマンドで、対処手順やポリシーモジュール作成方法が提示されます。
- ■ journalctl -t setroubleshoot: setroubleshootd のログを表示
- ■ sealert -l <message_ID>: AVC メッセージ ID から詳細レポートを取得
実行ユーザー：root または sudo 権限ユーザー
目的：setroubleshoot レポートで原因と推奨アクションを把握する
期待される結果：エラー内容、関連ポリシー、audit2allow コマンド例などが表示される
#!/bin/bash
# 最近の setroubleshootd ログを表示（24 時間以内）
journalctl -t setroubleshoot --since "2025-05-10 00:00" # -t でタグ指定、--since で時間フィルタリング
# 特定 AVC メッセージの詳細レポートを表示
sealert -l e9d8fa2e-3608-4ffa-9e72-31a1b85e460b # 実際に表示された Message ID を指定
また、特定アプリケーションに対しては SELinux ブール値を切り替えることで柔軟に対応できます。たとえば HTTPD のネットワーク接続を許可する場合：
#!/bin/bash
# HTTPD のネットワーク接続ブール値を確認
getsebool -a | grep httpd_can_network_connect # ブール一覧から httpd 系オプションを抽出
# 永続的にネットワーク接続を許可
setsebool -P httpd_can_network_connect on # -P で永続反映
# 非標準ポートを追加する例
semanage port -a -t http_port_t -p tcp 8080 # 8080/TCP を http_port_t に割り当て
SEMANGE や GETSEBOOL/SETSEBOOL に関する詳細は SELinux Policy 管理ドキュメントを参照してください。
14.5.3 ファイルコンテキスト設定と restorecon
ファイルやディレクトリの SELinux コンテキストが不整合になるとアクセス拒否が発生します。restorecon や semanage fcontext で正しいコンテキストを再設定し、永続的に維持します。
- ■ ls -Z: 現在の SELinux コンテキストを確認
- ■ restorecon: デフォルトポリシーに基づきコンテキストを修復
- ■ semanage fcontext: カスタムパスのコンテキスト定義
実行ユーザー：root または sudo 権限ユーザー
目的：不整合が疑われる対象のコンテキストを正しく再設定する
期待される結果：指定パス以下のファイルが適切なコンテキストに修復される
#!/bin/bash
# 対象ディレクトリの現在コンテキストを表示
ls -Z /var/www/html # デフォルトのウェブルートコンテキストを確認
# デフォルトポリシーに基づき再帰的にコンテキストを修復
restorecon -Rv /var/www/html # -R で再帰、-v で詳細表示
# カスタムパスに新規コンテキストを設定
semanage fcontext -a -t httpd_sys_content_t "/data(/.*)?" # /data 配下を httpd_sys_content_t に設定
# カスタム定義を反映
restorecon -Rv /data # 新規設定を適用するため再度 restorecon 実行
-d オプションで削除してください。14.6 ストレージ・ファイルシステム関連の問題解決
AlmaLinux9環境でのストレージ関連トラブルは、データ損失やサービス停止に直結するため、迅速かつ確実な対応が求められます。本節では、ローカルファイルシステムの整合性修復、LVMボリュームのトラブルシューティング、ソフトウェアRAID (mdadm) の障害対応を、実際に動作するスクリプト例とともに詳しく解説します。
14.6.1 ファイルシステムの不整合修復（fsck, xfs_repair）
ext2/ext3/ext4ファイルシステムは e2fsck（fsck.ext4 などのハードリンク）が、XFSは xfs_repair が不整合チェック・修復を行います。いずれも対象をアンマウントしてから実行する必要があります。
- ■ e2fsck: ext4などのジャーナリングファイルシステムをチェック・修復します
- ■ xfs_repair: XFSのメタデータ不整合を修復します
実行ユーザー：rootまたはsudo権限ユーザー
目的：ファイルシステムの整合性をチェックし、必要に応じて自動修復する
期待される結果：アンマウントされたデバイス上のエラーが検出・修復され、再マウント可能になる
#!/bin/bash
# デバイス名を指定（例: /dev/sdb1 または /dev/mapper/myvg-mylv）
DEVICE="/dev/sdb1" # チェック対象デバイスを設定
# 1. ext4/ext3/ext2 ファイルシステムのチェック・修復
umount "${DEVICE}" # アンマウントしてファイルシステムを安全にする
e2fsck -n "${DEVICE}" # -n:修復せずチェックのみ実行（ドライラン） :contentReference[oaicite:2]{index=2}
e2fsck -y "${DEVICE}" # -y:全て自動承認で修復を実行
mount "${DEVICE}" # 修復後に再マウント
# 2. XFS ファイルシステムのチェック・修復
umount "${DEVICE}" # XFSも同様にアンマウントが必須
xfs_repair -n "${DEVICE}" # -n:ドライランで修復プランを表示 :contentReference[oaicite:3]{index=3}
xfs_repair "${DEVICE}" # 実際に修復を実行
mount "${DEVICE}" # 修復後に再マウント
echo "File system repair completed on ${DEVICE}" # 完了メッセージを表示
xfs_repair を実行すると、ログ再生だけで整合性が取れることがあります。14.6.2 LVM トラブルシューティング
LVMの障害はボリュームグループや物理ボリュームのメタデータ破損、デバイスフィルタ設定不備など多岐にわたります。-vオプションで詳細なログを取得し、pvdisplay、vgdisplay、lvdisplayで状態を確認しましょう。必要であれば pvck、vgcfgrestore によるメタデータ復旧を行います。
- ■ -vオプション：LVMコマンドで冗長なログを出力し原因を特定します
- ■ pvck/vgcfgrestore：物理ボリュームやVGメタデータを修復します
実行ユーザー：rootまたはsudo権限ユーザー
目的：LVMメタデータと論理ボリュームの状態を収集・修復する
期待される結果：/tmp/lvm-diag-$(hostname).tar.gz に診断ログが出力され、必要な修復操作を実行できる
#!/bin/bash
HOST="$(hostname)" # ホスト名を取得
OUTDIR="/tmp/lvm-diag-${HOST}" # 出力ディレクトリを設定
mkdir -p "${OUTDIR}" # ディレクトリを作成
# LVMの基本情報を収集
pvdisplay -v > "${OUTDIR}/pvdisplay.log" # 物理ボリューム情報をボリューム別に表示 :contentReference[oaicite:6]{index=6}
vgdisplay -v > "${OUTDIR}/vgdisplay.log" # ボリュームグループ情報を詳細表示 :contentReference[oaicite:7]{index=7}
lvdisplay -v > "${OUTDIR}/lvdisplay.log" # 論理ボリューム情報を詳細表示 :contentReference[oaicite:8]{index=8}
# LVMメタデータのダンプ（再構築用）
vgcfgbackup -f "${OUTDIR}/vg-${HOST}.backup" # VGメタデータをファイルに保存 :contentReference[oaicite:9]{index=9}
# 収集結果を圧縮
tar -czf "/tmp/lvm-diag-${HOST}.tar.gz" -C "${OUTDIR}" . # ディレクトリを一括圧縮
# 一時ディレクトリを削除
rm -rf "${OUTDIR}" # 作業用ディレクトリをクリーンアップ
echo "LVM diagnostic data saved to /tmp/lvm-diag-${HOST}.tar.gz" # 完了通知
pvck、vgcfgrestore）は慎重に実行してください。誤操作でデータ全損のリスクがあります。
14.6.3 RAID 故障時の mdadm 操作
ソフトウェアRAID (mdadm) においてディスク故障が発生した場合、/proc/mdstat や journalctl -k で障害を特定し、mdadm --manage オプションでフェイル、リムーブ、スペア追加、再構築を行います。
- ■ –fail: 故障ディスクをRAIDから切り離します
- ■ –remove: 切り離したディスク情報をクリアします
- ■ –add: 新しいディスクをスペアとして追加します
実行ユーザー：rootまたはsudo権限ユーザー
目的：故障ディスクの交換とRAID再構築を自動化する
期待される結果：/dev/md0 の再同期が開始され、正常なRAID状態に復旧する
#!/bin/bash
MDDEV="/dev/md0" # RAIDデバイスを設定
BADDEV="/dev/sdd" # 故障ディスクを指定
SPAREDEV="/dev/sde" # 代替ディスクを指定
# 1. カーネルログで故障を確認
journalctl -k | grep -i "md/raid" # md/raidドライバの故障ログを抽出
# 2. 故障ディスクをフェイル扱いにする
mdadm --manage "${MDDEV}" --fail "${BADDEV}" # 故障ディスクをマークしてIOを停止 :contentReference[oaicite:10]{index=10}
# 3. RAIDアレイから削除
mdadm --manage "${MDDEV}" --remove "${BADDEV}" # RAID構成情報からディスクを削除 :contentReference[oaicite:11]{index=11}
# 4. スペアディスクを追加して再構築開始
mdadm --manage "${MDDEV}" --add "${SPAREDEV}" # 新ディスクをスペアとして追加し再同期開始 :contentReference[oaicite:12]{index=12}
# 5. 現在の同期状況を表示
watch -n 5 "cat /proc/mdstat" # 5秒ごとに同期状況をリアルタイム確認
echo "RAID rebuild initiated on ${MDDEV}" # 完了メッセージを表示
14.7 サービス起動と systemd 関連の問題
AlmaLinux9 ではほとんどのサービス管理が systemd により行われます。サービスが期待どおりに起動しない、異常停止を繰り返す場合は、systemctl と journald のログを活用して原因を特定しましょう。本節では「状態確認」「ユニット文法検証」「自動起動設定」の観点から徹底的に解説します。
14.7.1 systemctl status と journalctl -u の活用
まずはサービスの現状を把握します。systemctl status でユニットの起動状態・依存関係・最近のログを、journalctl -u で詳細ログを取得し、エラーや警告を確認しましょう。
# httpd サービスのステータスを表示（起動状態・依存関係・最新ログ含む）
systemctl status httpd.service --no-pager --full # --no-pager: ページャを無効化、--full: ログを省略せず全出力
# httpd サービスのログを 2025-05-10 以降で取得
journalctl -u httpd.service --since "2025-05-10 00:00" --no-pager # --since で開始時刻を指定し全ログ表示
# 複数サービスを一括チェックするスクリプト例
#!/bin/bash
SERVICES=(httpd mariadb sshd) # チェック対象のサービス名配列
for svc in "${SERVICES[@]}"; do # 配列をループ処理
echo "=== ${svc} ===" # サービス名を見出し表示
systemctl is-active "${svc}" && systemctl status "${svc}" --no-pager --quiet \
|| echo "${svc} はアクティブではありません" # 起動中か判定し、停止中ならメッセージ出力
done
systemctl status は標準エラー出力にもメッセージを出すため、パイプで別コマンドに渡す場合はリダイレクトに注意してください。
14.7.2 ユニットファイルの文法エラー検出
ユニット定義ファイル（/etc/systemd/system/*.service 等）に文法ミスがあると、サービス起動時にエラーとなります。systemd-analyze verify で検証し、問題箇所を特定しましょう。
# カスタムユニットファイルの文法を検証
systemd-analyze verify /etc/systemd/system/myapp.service # 検証結果にエラー行が表示される
# /etc/systemd/system 配下の全ユニットを一括検証するスクリプト
#!/bin/bash
for unit in /etc/systemd/system/*.service; do # 全 service ファイルをループ処理
echo "Verifying ${unit}" # 検証対象ファイルを表示
systemd-analyze verify "${unit}" 2>&1 | grep -E "error" \
&& echo "文法エラー検出: ${unit}" # エラー含む場合に通知
done
systemctl daemon-reload を必ず実行し、新しい定義を systemd に認識させてください。
14.7.3 自動起動設定の確認とトラブル対応
サービスの自動起動（enable）設定が正しくないと、再起動後にサービスが立ち上がりません。systemctl is-enabled、list-unit-files で確認し、必要に応じて設定を修正します。
# nginx サービスの自動起動設定を確認
systemctl is-enabled nginx.service # enabled, disabled, static などを表示
# 全サービスの自動起動設定一覧から disabled を抽出
systemctl list-unit-files --type=service | grep disabled # disabled サービスを一覧表示
# 自動起動設定の修正例
systemctl enable myapp.service # 自動起動を有効化
systemctl disable oldservice.service # 自動起動を無効化
# 自動起動設定と現在の起動状態をまとめて確認するスクリプト
#!/bin/bash
echo "Service Enabled Active"
for svc in $(systemctl list-unit-files --type=service --no-legend | awk '{print $1}'); do
enabled=$(systemctl is-enabled "$svc" 2>/dev/null) # enable 状態を取得
active=$(systemctl is-active "$svc" 2>/dev/null) # active 状態を取得
printf "%-20s %-9s %s\n" "$svc" "$enabled" "$active" # 整形して出力
done
@.service）を使う場合は、実インスタンス名（例 foo@instance.service）で確認してください。14.8 ブートプロセスのトラブルシューティング
システム起動時の問題は、AlmaLinux 9 環境では深刻な障害に直結します。ブートローダー（GRUB）や initramfs、systemd プロセスのいずれかでトラブルが発生すると、システムが起動不能になることもあります。本節では、起動時間分析から initramfs の再生成、GRUB 設定の再構築まで、段階的にトラブルを切り分ける手順を解説します。
14.8.1 systemd-analyze で起動時間を可視化
起動が遅い、途中でタイムアウトになるなどの症状は、どのサービスやプロセスがボトルネックになっているかを特定することで解決に近づきます。systemd-analyze コマンドは以下のような機能を提供します。
- ■
time：カーネル、initramfs、ユーザースペースの起動時間を表示 - ■
blame：各サービスの起動時間を降順で一覧 - ■
critical-chain：依存関係に沿ったサービス起動のクリティカルパス表示
#!/bin/bash
# システム起動全体の時間内訳を表示
systemd-analyze time # カーネル・initrd・ユーザースペースの起動時間を出力
# 起動に最も時間を要したユニットを確認
systemd-analyze blame # 各サービスの起動時間を降順で表示
# 依存関係に基づくクリティカルパスを可視化
systemd-analyze critical-chain # 起動シーケンスと依存関係をツリー形式で表示
TimeoutStartSec を調整するなどの最適化が可能です。
14.8.2 dracut と initramfs の再生成
initramfs（初期RAMディスク）が壊れていたり、モジュール不足でルートファイルシステムまで辿り着けない場合は、dracut で再生成します。再生成後は必ず lsinitrd などで内容を確認しましょう。
実行ユーザー：root または sudo 権限ユーザー
目的：破損・欠落しているモジュールやドライバを含めた新規 initramfs を生成する
期待される結果：/boot/initramfs-$(uname -r).img が正しく再構築され、次回ブートで読み込まれる
#!/bin/bash
KVER="$(uname -r)" # 現在のカーネルバージョンを取得
# 現在の initramfs をバックアップ
cp /boot/initramfs-"${KVER}".img /boot/initramfs-"${KVER}".img.bak # 既存ファイルを退避
# 新規 initramfs を生成（-f で強制上書き）
dracut -f /boot/initramfs-"${KVER}".img "${KVER}" # カーネルモジュールを自動検出して img を再生成
# 生成結果を確認
lsinitrd /boot/initramfs-"${KVER}".img | head -n 20 # initramfs 内の先頭20行を表示して中身を確認
dracut の再生成には十分なディスク空き容量が必要です。また、モジュールを手動追加する場合は --add オプションを検討してください。
14.8.3 GRUB 設定の再構築と UEFI 対応
GRUB の設定やインストールが壊れていると、そもそもブートローダーが起動しません。BIOS（Legacy）と UEFI 環境それぞれで再インストール・設定生成を行い、grub.cfg を最新状態にしましょう。
実行ユーザー：root
目的：GRUB2 を正しいデバイスに再インストールし、設定ファイルを再生成する
期待される結果：次回起動時に GRUB メニューが正常に表示され、OS がブート可能になる
#!/bin/bash
ESP="/boot/efi" # UEFI 環境の EFI システムパーティションマウントポイント
GRUB_DEV="/dev/sda" # GRUB をインストールするディスクを指定
# 1. BIOS (Legacy) 環境向け GRUB 再インストール
grub2-install "${GRUB_DEV}" # MBR/GPT に GRUB を書き込む
# 2. UEFI 環境向けの再インストール（ESP がマウントされている場合）
mount | grep -q "${ESP}" || mount "${ESP}" # ESP が未マウントならマウント
grub2-install --target=x86_64-efi --efi-directory="${ESP}" --bootloader-id="almalinux" # EFI 用 GRUB を登録
# 3. grub.cfg の再生成
grub2-mkconfig -o /boot/grub2/grub.cfg # BIOS 用 grub.cfg を生成・上書き
grub2-mkconfig -o /boot/efi/EFI/almalinux/grub.cfg # UEFI 用 grub.cfg を生成・上書き
echo "GRUB reinstallation and config regeneration completed" # 完了メッセージを表示
fsck.vfat でチェックを行うことも検討してください。14.9 まとめとベストプラクティス
14.9.1 トラブルシューティング手順チェックリスト
- ✅
事象記録と再現性確認：障害発生時刻・影響範囲・再現手順を詳細にメモし、必ず同じ条件で再現テストを行います。 - ✅
ログ参照とキーワード検索：journalctlや/var/logを活用し、エラー／警告を優先度・タイムスタンプで絞り込みます。 - ✅
切り分けと仮説検証：ネットワーク、ファイルシステム、サービス、SELinux など要素ごとに二分探索的に絞り込み、順序立てて仮説を潰します。 - ✅
応急対応と恒久対策：まず業務継続に必要な回避策を適用し、その後根本原因を修正して再発防止を図ります。 - ✅
自動収集スクリプト活用：前節で示したロギング・ネットワーク・システム情報収集スクリプトを定期実行し、傾向分析に備えます。 - ✅
ドキュメント化とレビュー：対策手順・原因・学びをナレッジベースに記録し、定期的に見直して最新の運用マニュアルに反映します。
14.9.2 よくある注意点とヒント
- ■ 権限設定の確認：ログ解析やパケットキャプチャは root/sudo 権限が必須です。権限不足による解析漏れを防ぎます。
- ■ 環境差異の把握：本番環境とテスト環境でパッケージバージョンやカーネルパラメータが異なると再現性が損なわれるため、できる限り同一構成を維持します。
- ■ 依存関係の管理：dnf や SELinux ポリシー更新後は依存関係やブール値、モジュールを必ず確認し、問題発生前のスナップショットを活用してロールバック手順を用意します。
- ■ 定期的な健康チェック：AlmaLinux9 環境では
cronや systemd タイマーで自動診断スクリプトを定期実行し、早期に異常を検知します。 - ■ 最新情報のキャッチアップ：公式ドキュメント（AlmaLinux9、Red Hat ドキュメント）やセキュリティアドバイザリを定期的に確認し、セキュリティ設定（SELinux、firewalld）を最新に保ちます。
- ■ チーム連携とナレッジシェア：発生したトラブルと対応を定期的に振り返り、シェア会やドリルを行うことでチーム全体の対応力を強化します。
