Posted inLinux

LinuxでのKdump設定ガイド：カーネルクラッシュダンプの収集と重大なシステム障害の分析

Linux tutorial - IT technology blog
Linux tutorial - IT technology blog

原因不明のサーバーハング――sysadminの悪夢

本番環境で初めてカーネルパニックに直面したときのことを今でも覚えています——チームのメインデータベースを動かしているCentOS 7サーバーで、レイテンシを10ms以下に抑えるために1ヶ月かけてチューニングしたものでした。午前3時に、何の警告もなくそのサーバーが再起動しました。/var/log/messagesを確認すると、ログは途中で切れており——原因を示す行が一切残っていませんでした。障害を再現して原因を突き止めるまでに1週間近くかかり、犯人はバックアップソフトウェアのカーネルモジュールでした——まさか疑うとは思わなかったものです。

あのときkdumpを知っていれば、大幅な時間を節約できたはずです。Kdumpはカーネルがクラッシュした瞬間——システムが再起動する前に——RAMの全状態を記録します。このダンプファイルをcrashツールで分析することで、コールスタック、エラーが発生したコード行、障害の根本原因を正確に特定できます。

Kdumpの仕組み

クラッシュ中のカーネル（もはや信頼できない状態）に頼る代わりに、Kdumpはブート時に独立したRAM領域に読み込まれた小さなキャプチャカーネルを使用します。メインカーネルがパニックを起こすと、システムはこのキャプチャカーネルに切り替わり、RAMの全内容をvmcoreファイルに書き出してから正常に再起動します。

  • vmcore：書き出されたダンプファイル。通常/var/crash/に保存される
  • makedumpfile：vmcoreを圧縮・フィルタリングし、不要なRAMページを除去してサイズを削減する
  • crash：vmcoreを解析するツール。GDBに似たインターフェース
  • kernel-debuginfo：デバッグシンボルを含むパッケージ——crashがシンボル名を読むために必要

メモリの予約

キャプチャカーネルには、メインカーネルが触れない専用のRAM領域が必要です。この領域は、ブートパラメータcrashkernel=で宣言します。通常、ほとんどのシステムでは128〜256MBで十分です。

Kdumpのインストールと設定（ステップバイステップ）

ステップ1：必要なパッケージのインストール

RHEL/CentOS/AlmaLinuxの場合：

sudo dnf install kexec-tools crash kernel-debuginfo kernel-debuginfo-common
# CentOS 7はyumを使用
sudo yum install kexec-tools crash kernel-debuginfo kernel-debuginfo-common

Ubuntu/Debianの場合：

sudo apt-get install kdump-tools crash linux-image-$(uname -r)-dbgsym

ステップ2：GRUBにcrashkernelを追加する

このステップがKdumpの動作を左右します——キャプチャカーネルには専用のRAM領域が必要で、crashkernel=がブートローダーにそれを宣言する方法です。/etc/default/grubを開きます：

sudo vi /etc/default/grub

# GRUB_CMDLINE_LINUXの行を見つけ、末尾にcrashkernel=autoを追加する
GRUB_CMDLINE_LINUX="... crashkernel=auto"

# grub設定を更新する（BIOS）
sudo grub2-mkconfig -o /boot/grub2/grub.cfg

# UEFIの場合
sudo grub2-mkconfig -o /boot/efi/EFI/centos/grub.cfg

再起動後、crashkernelが予約されているか確認します：

cat /proc/iomem | grep -i crash
# 期待される出力：
# 2d000000-4cffffff : Crash kernel

ステップ3：/etc/kdump.confの設定

sudo vi /etc/kdump.conf

ローカルディスクにダンプを保存するための基本設定：

# vmcoreの保存パス
path /var/crash

# ダンプ完了後のアクション
default reboot

# makedumpfileを使用して圧縮し、不要なページを除外する
core_collector makedumpfile -l --message-level 1 -d 31

-d 31パラメータは、ゼロページ、キャッシュページ、およびエラーに無関係なページを除去します。これにより、ダンプファイルは実際のRAMサイズの10〜20%程度に縮小されます——16GBのサーバーであれば2〜3GB程度になるのは普通のことです。

ローカルディスクの使用を避けてNFS共有にダンプを書き出す場合：

nfs 192.168.1.100:/exports/crash_dumps
path /

ステップ4：kdumpサービスの有効化と起動

sudo systemctl enable kdump
sudo systemctl start kdump
sudo systemctl status kdump

起動が成功すると、以下のように表示されます：

● kdump.service - Crash recovery kernel arming
   Loaded: loaded (/usr/lib/systemd/system/kdump.service; enabled)
   Active: active (exited) since Wed 2026-06-25 10:30:00 JST

ステップ5：Kdumpのテスト（テスト環境のみで実施！）

Kdumpが正しく動作することを確認するには、意図的にカーネルパニックを発生させる必要があります。以下のコマンドはサーバーを即座にクラッシュさせます——VMまたはテストサーバーでのみ実行してください：

# 警告：サーバーは即座にクラッシュして再起動します
echo 1 > /proc/sys/kernel/sysrq
echo c > /proc/sysrq-trigger

サーバーが再起動したら、ダンプディレクトリを確認します：

ls -lh /var/crash/
# drwxr-xr-x 2 root root 4096 Jun 25 10:35 2026-06-25-10:35

ls -lh /var/crash/2026-06-25-10:35/
# vmcore              -- メインのダンプファイル
# vmcore-dmesg.txt    -- クラッシュ前のカーネルメッセージ

crashツールを使ったカーネルクラッシュダンプの解析

crashでvmcoreを開く

# 構文：crash <vmlinux> <vmcore>
sudo crash /usr/lib/debug/lib/modules/$(uname -r)/vmlinux \
           /var/crash/2026-06-25-10:35/vmcore

crashシェルに入ったら、以下のコマンドだけで90%のケースに対応できます：

# クラッシュ時のコールスタック
crash> bt

# クラッシュ前のカーネルログ
crash> log

# 実行中のプロセス一覧
crash> ps

# クラッシュの概要情報
crash> sys

# メモリの状態
crash> kmem -i

# 終了
crash> quit

バックトレースの読み方

btの出力はこのようになります：

crash> bt
PID: 0      TASK: ffffffff81c14480  CPU: 0   COMMAND: "swapper/0"
 #0 [ffffffff81c03d28] machine_kexec at ffffffff8105b6ab
 #1 [ffffffff81c03d78] __crash_kexec at ffffffff810f2d5a
 #2 [ffffffff81c03e48] crash_kexec at ffffffff810f2e50
 #3 [ffffffff81c03e60] oops_end at ffffffff8162efb8
 #4 [ffffffff81c03e88] die at ffffffff8101e97b
 #5 [ffffffff81c03eb8] do_general_protection at ffffffff8162e834

下から上に読みます——スタックの末尾にある関数が問題の発生源です。私の場合、バックトレースはバックアップソフトウェアのモジュールをズバリ指し示していました——まったく疑っていなかったものです。

vmcoreからdmesgを素早く抽出する

深い分析が不要な場合は、クラッシュ前のカーネルメッセージを素早く取得できます：

makedumpfile --dump-dmesg /var/crash/2026-06-25-10:35/vmcore dmesg.txt
cat dmesg.txt | tail -50

通常、Kernel panicの直前のエラー行だけで調査を始めるには十分です——crashシェルに深く潜らなくてもよいことが多いです。

実運用でのポイント

  • ディスク容量：少なくとも1〜2個のダンプファイル分のスペースを確保してください。16GBのRAMは圧縮後でも/var/crashに3〜5GBの空きが必要です
  • kernel-debuginfoはproductionサーバーに不要：このパッケージは数GB程度あります。解析マシンにのみインストールし、vmcoreをそこにコピーすれば十分です
  • カーネルバージョンは完全に一致させること：vmlinux（debuginfo）はvmcoreを生成したカーネルと完全に同じバージョンでなければなりません。バージョンが違うとcrashツールが即座にエラーを出します
  • 大容量RAMサーバーではcrashkernel=autoが不足する場合あり：64GB以上のサーバーでは、kdumpサービスの起動に失敗する場合、crashkernel=512Mを手動で指定する必要があることがあります
  • 定期的なクリーンアップ：サーバーが連続してクラッシュした場合にディスクが埋まらないよう、古いダンプを削除するcronを追加してください

まとめ

Kdumpは毎日使うものではありません。しかし、サーバーが痕跡を残さずにカーネルパニックを起こしたとき、本当の答えを与えてくれる唯一のツールです。セットアップは約30分——その代わりに、障害発生時に何日もの手探りを避けられます。

カスタムカーネルモジュール、特殊なハードウェアドライバー、または高負荷のデータベースワークロードを実行しているサーバーには、特にKdumpが必要です。障害が起きる前から有効にしておくことが重要です——必要になったときには、もう有効にする機会はありません。

Share:
Tags: