AlmaLinux 9 総合ガイド 第１４章

2025.01.25

第14章: トラブルシューティングと問題解決

14.1 この章で解説する主要な技術・概念

サーバー運用では、トラブルをいかに素早く発見し、正確に切り分け、最小のダウンタイムで復旧するかが重要です。本章では、AlmaLinux 9上で考えられるさまざまな問題のトラブルシューティング方法を深掘りします。ログ解析やシステムコマンドの活用だけでなく、SELinuxやファイルシステム、ネットワークなどの仕組みを理解しておくことで、根本原因へ素早くたどり着き、適切な対処が可能になります。

  1. トラブルシューティングの基本フロー
  2. ログファイル解析 (journalctl, /var/log ディレクトリ)
  3. ネットワーク関連問題の切り分け (ping, traceroute, ss, ip, tcpdump)
  4. SELinux関連の問題 (コンテキストエラー、ポリシー違反)
  5. ファイルシステム・ストレージ関連の問題 (fsck, xfs_repair, LVM/RAID故障)
  6. サービス起動・systemd関連の問題
  7. ブート関連の問題 (systemd-analyze, dracut, GRUB設定)

14.2 トラブルシューティングの基本フロー

14.2.1 問題の把握と再現性確認

  1. 症状の確認: サービスが応答しない、ログインできない、エラーメッセージの表示など
  2. 影響範囲の把握: 該当ホストだけか、複数ノードにも広がっているか
  3. 再現方法: コマンド実行や特定の操作で確実に問題が起きるかを確認

再現性がない場合はログや監視履歴を掘り返して類似パターンを探す必要がある。

14.2.2 ログの参照とヒアリング

  • ログファイル（journalctl, /var/log/messages, /var/log/secure など）を概観
  • 特定の時刻やサービス (journalctl -u servicename) に絞り、関連するエラーメッセージをチェック
  • ユーザーや監視システムからの報告やスクリーンショットを確認し、実際にどんなエラーが出たか収集

14.2.3 切り分けと対処

  • ネットワークかシステム資源不足かサービス設定ミスか、徐々に対象を絞り込む
  • 応急処置（サービス再起動、負荷分散先の切り替え）と恒久対策（設定修正、ハードウェア増強）を分けて考える

14.3 ログファイル解析

14.3.1 journalctlの高度な活用

# ブートごと
journalctl -b
# 指定ユニット
journalctl -u httpd.service
# 時間範囲
journalctl --since "2025-01-20 09:00" --until "2025-01-20 10:00"
  • -p err や -p warning を使って重大度レベルを絞り込む
  • -o cat などで出力形式を変更して見やすくする

14.3.2 /var/log ディレクトリ

  • /var/log/messages: システム全般のイベント、cron, kernel, daemonなど
  • /var/log/secure: SSHやsudoなどの認証関連ログ
  • /var/log/dnf.log: パッケージインストール・更新履歴
  • /var/log/audit/audit.log: SELinuxやauditd関連の詳細ログ（拒否イベントなど）

grepでのキーワード検索

grep "Out of memory" /var/log/messages
grep -i "failed" /var/log/secure
  • 必要に応じてzgrepで圧縮済みログ(.gz)を検索

14.4 ネットワーク関連問題の切り分け

14.4.1 疎通確認 (ping, traceroute)

  • ping -c 4 192.168.10.1 でICMPエコーを送信し、到達性とラウンドトリップ時間を確認
  • traceroute 8.8.8.8 でルーティング経路を把握し、中継ルーターでの遅延やドロップを調査

ファイアウォールやICMP制限の関係でpingが通らない場合もあるため、単純にping不能=障害とは限らない。

14.4.2 ss (ソケットステータス) と ip コマンド

ss -tln
  • TCPポートをLISTENしているソケット一覧を表示
  • SSHやHTTPが想定のポートで待ち受けているか、他のプロセスと競合していないかを確認
ip addr show
ip route show
  • IPアドレスやデフォルトゲートウェイが正しいかチェック
  • 複数NIC構成やVLAN設定でルーティングが誤っていないか

14.4.3 tcpdumpによるパケットキャプチャ

sudo tcpdump -i enp0s3 port 80 -nn -vv
  • HTTP(80)のパケットをキャプチャし、クライアントとサーバー間の通信が正しく行われているか確認
  • DNSやSSHなどトラブルの際にも有効。通信そのものが到達していないのか、レスポンスが来ないのか切り分ける

14.5 SELinux関連の問題

14.5.1 AVC拒否ログと解析

  • AVC (Access Vector Cache) 拒否があると、audit.log や journalctl -t setroubleshoot に「SELinuxが○○を拒否しました」というメッセージが記録
  • ausearch -m avc -ts recent でAVC拒否ログの詳細を検索

14.5.2 setroubleshootを使った対処

sudo dnf install setroubleshoot
sudo journalctl -f -t setroubleshoot
  • ログ出力に合わせて「SELinux拒否が起きた原因」と「policyモジュールを追加すると解決できる」といった提案メッセージが表示される場合がある

注意: 提案されるpolicyを無作為に受け入れると、セキュリティホールが生まれる可能性があるため、内容を理解してからカスタムポリシーを適用すること。

14.5.3 ファイルコンテキストとrestorecon

ls -Z /var/www/html/
sudo semanage fcontext -a -t httpd_sys_content_t "/var/www/html(/.*)?"
sudo restorecon -Rv /var/www/html
  • Webサーバー用コンテンツにhttpd_sys_content_tが付与されていないとアクセス拒否になるケースが典型的
  • chcon は一時的、semanage fcontext+restorecon が恒久的設定

14.6 ファイルシステム・ストレージ関連の問題

14.6.1 ファイルシステムの不整合 (fsck, xfs_repair)

  • ext4: sudo fsck -f /dev/sdb1 (アンマウントした状態で実行)
  • XFS: sudo xfs_repair /dev/sdb1 (xfsはfsckではなくxfs_repair)

注意: アンマウントしないと修復ツールが動作しない場合が多い。最悪、再起動後にシングルユーザーモードに入り手動修復を行う。

14.6.2 LVMトラブル

sudo pvs
sudo vgs
sudo lvs
  • 物理ボリューム(PV)やボリュームグループ(VG)、論理ボリューム(LV)がUnknownになっていないか
  • メタデータの破損時はvgcfgrestore でバックアップから復元する方法もある

14.6.3 RAID故障 (mdadm)

  • mdadm --detail /dev/md0 でRAIDアレイの状態を確認し、State : clean, degraded などをチェック
  • 故障ディスクをmdadm --remove /dev/md0 /dev/sdb1 し、新ディスクを追加 (mdadm --add /dev/md0 /dev/sdb1) して再同期を待つ
  • 同期が完了するまでI/O性能が落ちるため、サービス影響にも注意

14.7 サービス起動・systemd関連の問題

14.7.1 systemctl statusとjournalctl -u

  • systemctl status httpd などでサービスの現在状態やエラーメッセージを瞬時に確認可能
  • journalctl -u httpd で起動時のログやエラーを追跡

14.7.2 ユニットファイルの文法エラー

sudo systemd-analyze verify /etc/systemd/system/myapp.service
  • syntaxエラーがあれば表示される。typoやセクション名の誤りに注意

例: myapp.service

[Unit]
Description=My custom application
After=network.target

[Service]
Type=simple
ExecStart=/usr/local/bin/myapp
Restart=on-failure

[Install]
WantedBy=multi-user.target
  • ExecStartに間違ったパスを指定していたり、[Install]セクションが無いと有効化できないなどのトラブルが起こりがち

14.7.3 自動起動の設定

  • systemctl enable でマルチユーザターゲットにリンクを張り、ブート時に起動
  • systemctl is-enabled で有効化状況をチェック
  • サービスが繰り返しクラッシュする場合はRestart=always としつつもログ解析で根本原因を調べることが重要

14.8 ブート関連の問題

14.8.1 systemd-analyze

systemd-analyze
systemd-analyze blame
systemd-analyze critical-chain
  • ブート完了までの時間や、サービスごとの起動時間を表示
  • blame で起動に時間がかかっているサービスを特定し、設定を見直す

14.8.2 dracutとカーネルイメージ

  • カーネルアップデート時にinitramfsを生成する仕組みがdracut
  • dracut -f /boot/initramfs-$(uname -r).img $(uname -r) で再生成できる
  • カスタムモジュールを入れる際は/etc/dracut.conf.d/配下で指定

14.8.3 GRUB関連の問題

  • /boot/grub2/grub.cfg などに誤記があるとブート不能になる
  • grub2-mkconfig -o /boot/grub2/grub.cfg で再生成
  • UEFI環境では /boot/efi/EFI/almalinux/grub.cfg が使われる場合もあり

14.9 学習のまとめ

  1. トラブルシューティングの基本フロー: 症状把握 → ログ解析 → ネットワーク/リソース/サービスの切り分け → 応急処置＆恒久対策。
  2. ログファイル解析: journalctl, /var/log配下を中心に、エラーや警告を抽出して根本原因を探す。
  3. ネットワーク関連: ping, traceroute, ss, ip route, tcpdump などで疎通やパケットレベルの問題を切り分け。
  4. SELinux関連: AVC拒否ログを確認し、必要に応じてコンテキスト変更やカスタムポリシーを適用。setroubleshootやausearchが情報収集を助ける。
  5. ファイルシステム・ストレージ: fsck, xfs_repair, mdadm --detail, lvm コマンドを駆使し、ディスク障害や不整合を修復。LVMやRAIDのメタデータ破損にも備える。
  6. サービス起動・systemd: systemctl status, journalctl -u でエラー原因を特定し、ユニットファイルの構文エラーや依存関係を検証。
  7. ブート関連: systemd-analyze で遅延や失敗を分析、dracut や GRUB 設定を見直し、ブート不能や遅延を解消。

次章へのつながり

次の章（第15章）では、AlmaLinux 9の総仕上げとして、ベストプラクティスと実践的なケーススタディを深堀りします。これまで学んだ設定・セキュリティ・自動化・監視技術をどのように組み合わせて実際の企業システムやWebサービス環境を構築・運用するか、具体的な事例をもとに総合的に学習していきましょう。