kdumpで取得したカーネルクラッシュダンプを本番環境で活用する収集設計と原因特定フロー

カーネルパニックを「記録」するためにkdumpが必要な理由

Linuxカーネルがパニックを起こすと、システムはほぼ即座に停止または自動再起動します。再起動後にログを見ても、/var/log/messagesやjournalctlには「kernel: Oops」あるいは「BUG: unable to handle kernel NULL pointer dereference」といった断片的な行が残る程度で、パニック直前のメモリ状態——スタックトレース、ロックの保持状況、実行中のプロセスの詳細——は失われてしまいます。

kdumpはこの問題に対応するための仕組みです。通常カーネルがクラッシュした直後、あらかじめ予約しておいた物理メモリ上で「キャプチャカーネル（capture kernel）」を起動し、クラッシュ時のメモリイメージ（vmcore）をストレージやネットワーク先に書き出してから再起動します。vmcoreが手元にあれば、crashユーティリティを使ってオフラインでクラッシュ時点の状態を詳細に再現できます。

本番環境でkdumpを整備しておく意義はとくに大きく、「再現性が低い・再現条件が不明なカーネルパニック」の調査に決定的な証拠を提供します。再現待ちで数日を費やすよりも、1回のクラッシュで採取したvmcoreを分析する方が原因特定が格段に早まります。

kdumpの仕組みと本番向け収集設計の基本方針

kdumpの動作は大きく2段階に分かれます。第1段階は「通常カーネルの動作中」、第2段階は「クラッシュ後のキャプチャカーネル起動中」です。

第1段階では、起動パラメーターcrashkernel=で指定したメモリ領域がキャプチャカーネル用に確保されます。この領域は通常カーネルからは隔離されているため、クラッシュ後もメモリ内容が保全されます。第2段階では、kexecによってキャプチャカーネルが起動し、makedumpfileがクラッシュメモリを読み取って圧縮・フィルタリングしたvmcoreを生成します。

本番環境での収集設計では、次の3点を事前に決めておくことが重要です。

• 保存先の選択：ローカルディスク（path）、NFS、SSH経由のリモートホストから選択します。ディスク障害が原因のパニックに備えてリモート保存を推奨します。
• ダンプレベルの設定：makedumpfileの-dオプションで除外するページを指定します。本番では-d 31（ゼロページ・キャッシュ・匿名ページ等を除外）が一般的で、ファイルサイズを数分の1に削減できます。
• 予約メモリ量の見積もり：搭載メモリが多いほど大きな値が必要です。RHELやAlmaLinuxではcrashkernel=autoが利用可能ですが、autoが想定外の値を選ぶケースもあるため、本番では明示的な指定（例：crashkernel=512M）が安全です。

kdumpの設定手順——カーネルパラメーターからサービス有効化まで

ここではRHEL9系（AlmaLinux 9・Rocky Linux 9を含む）を基準に手順を説明します。Ubuntuについては後述の差分節を参照してください。

1. kexec-toolsのインストールとcrashkernelパラメーターの設定

sudo dnf install -y kexec-tools
sudo grubby --update-kernel=ALL --args="crashkernel=512M"
# 変更確認
sudo grubby --info=DEFAULT | grep args

GRUBの設定変更後、再起動が必要です。再起動後にcat /proc/cmdlineでcrashkernel=512Mが含まれていることを確認します。

2. /etc/kdump.confの主要設定

/etc/kdump.confがkdumpの動作を制御します。最低限押さえるべき項目は以下のとおりです。

# ローカルに保存する場合（デフォルト）
path /var/crash

# NFS経由でリモートに保存する場合（例）
# nfs 192.0.2.10:/exports/kdump

# makedumpfileのフィルタレベル
core_collector makedumpfile -l --message-level 7 -d 31

# クラッシュ後の動作（reboot / halt / poweroff / shell）
default reboot

-lオプションはLZO圧縮を有効にし、--message-level 7は収集中の進捗メッセージをコンソールに出力します。本番ではdefault rebootとしてサービス復旧を優先させつつ、vmcoreは確実に書き出す構成が一般的です。

3. kdumpサービスの有効化

sudo systemctl enable --now kdump
sudo systemctl status kdump

systemctl status kdumpの出力に「Kdump is operational」と表示されれば、キャプチャカーネルがメモリにロードされた状態です。「No memory reserved for crash kernel」と出る場合はcrashkernelパラメーターが未反映ですので、再起動の確認から見直します。

ダンプ取得後の動作検証——SysRqによるテストクラッシュ

本番投入前に、kdumpが実際にvmcoreを生成できるかをテスト環境で検証します。SysRqのパニックトリガーを使う方法が最も確実です。

まずSysRqが有効になっていることを確認します。

cat /proc/sys/kernel/sysrq
# 1 または 176 等が返ればOK（0は無効）
sudo sysctl -w kernel.sysrq=1

次に意図的なパニックを発生させます。このコマンドを実行するとシステムは即座にクラッシュします。テスト環境のみで実行してください。

sudo sh -c 'echo c > /proc/sysrq-trigger'

再起動後、/var/crash/以下に日時のディレクトリが作成され、その中にvmcoreとvmcore-dmesg.txtが存在すれば収集成功です。vmcore-dmesg.txtにはクラッシュ直前のカーネルログが含まれており、簡易確認に使えます。

ls -lh /var/crash/$(ls /var/crash | tail -1)/
# vmcore と vmcore-dmesg.txt があることを確認

crashユーティリティによる原因特定フロー

vmcoreを分析するにはcrashコマンドと、クラッシュしたカーネルに対応するデバッグシンボル（debuginfo）が必要です。

crashとdebuginfoのインストール

# RHEL9系
sudo dnf install -y crash
sudo dnf debuginfo-install -y kernel

# Ubuntuの場合（ddeb リポジトリ経由）
sudo apt-get install -y crash linux-image-$(uname -r)-dbgsym

crashの起動にはvmcoreとカーネルのvmlinuxファイルを指定します。

sudo crash /usr/lib/debug/lib/modules/$(uname -r)/vmlinux \
           /var/crash/2026-10-28-XX:XX/vmcore

原因特定に使う主要コマンド

crashプロンプトに入ったあと、まず以下のコマンドを順に実行します。

crash> log
# カーネルリングバッファのログを全件表示。パニックの直接メッセージがここに出る

crash> bt
# クラッシュしたCPUのスタックトレースを表示。どの関数呼び出しでパニックが起きたかを確認

crash> bt -a
# 全CPUのスタックトレースを一覧表示。デッドロック調査に有効

crash> ps
# クラッシュ時点の全プロセス一覧。[RUN]状態のプロセスに着目する

crash> vm
# 現在のプロセスの仮想メモリマップを表示

crash> files
# クラッシュしたプロセスが開いていたファイルディスクリプタの一覧

logの出力では「BUG:」「Oops:」「general protection fault」「kernel NULL pointer dereference」などのキーワードを探します。その後に続くRIPレジスタの値（例：RIP: 0010:some_function+0x1c/0x40）がクラッシュした関数と命令オフセットを示しています。

btのスタックトレースと照合することで、どのドライバ、サブシステム、またはユーザー空間のシステムコールがパニックに至ったかを追跡できます。NULLポインタ参照の場合はstructメンバーのオフセットと照らし合わせて、どのフィールドが未初期化だったかをstructコマンドで確認します。

# 構造体のレイアウト確認（例：task_struct）
crash> struct task_struct.comm,pid ffff888012345678

2026年現行環境での注意点と差分

kdumpを取り巻く環境は2024〜2026年にかけていくつかの重要な変化があります。本番環境のディストリビューションに応じて以下を確認してください。

RHEL9系・AlmaLinux9・Rocky Linux9

RHEL9ではkdumpサービスの内部実装がPython製のスクリプトからsystemdネイティブの処理に整理されつつあり、kdump.confの一部オプションが非推奨になっています。とくにnetオプションによるネットワーク設定は廃止され、nfsまたはsshを個別に指定する形が標準です。設定変更後はsudo kdumpctl rebuildでキャプチャカーネルを再構築することを忘れないようにしてください。

Ubuntu 22.04 / 24.04

Ubuntuではkdumpの設定は/etc/default/kdump-toolsで管理されます。crashkernel=はGRUBの設定ファイルではなくkdump-tools経由で制御するため、RHELと手順が異なります。sudo kdump-config showでキャプチャカーネルのロード状態を確認できます。Ubuntu 24.04ではddebrepoが標準で有効になっており、linux-image-*-dbgsymパッケージの取得が以前よりも簡単です。

KASLRとvmcoreの読み取り

カーネル5.x以降でKASLR（カーネルアドレス空間配置のランダム化）が標準有効になっています。crashはvmcore内のKASLRオフセット情報を自動で読み取るため、通常は意識する必要はありませんが、古いバージョンのcrash（7.x以前）ではKASLRオフセットの解析に失敗するケースがあります。RHEL9・Ubuntu 24.04の標準パッケージはcrash 8.x系が提供されているため、ディストリビューション付属のバージョンを使うのが安全です。

IBM POWER環境のfadump

IBM POWERアーキテクチャでは、kdumpではなくfadump（Firmware Assisted Dump）が推奨されます。fadumpはファームウェアレベルでメモリを保全するため、kdumpよりも信頼性が高く、captureカーネル用のメモリ予約も少なくて済みます。POWER環境にkdumpの手順をそのまま適用するとブート障害になるケースがあるため、アーキテクチャの確認は必須です。

よくあるつまずき点

• vmcoreが生成されない：systemctl status kdumpが「operational」でも、保存先のパーティションに空きが不足していると書き出しが途中で失敗します。vmcoreのサイズは物理メモリの10〜30%程度（makedumpfileのフィルタレベル次第）を見込んでください。
• crashが「cannot resolve symbol」で起動しない：インストールしたdebuginfoのカーネルバージョンとvmcoreのカーネルバージョンが一致していない場合に発生します。crash -vとuname -r（vmcore-dmesg.txtに記載）を照合してください。
• セキュアブート環境でkexecが失敗する：セキュアブートが有効な環境では、kexecによるキャプチャカーネルのロードが署名検証でブロックされることがあります。ディストリビューション提供の署名済みkexec-toolsを使うか、セキュアブートのポリシーをMOK（Machine Owner Key）で対応します。

kdumpの整備は「障害が起きてから考える」では間に合いません。本番環境への適用前にテスト機でSysRqによるダンプ取得とcrashでの読み取りまで通しておくことで、実際の障害時に落ち着いて調査を進められる体制が整います。ディストリビューションのバージョンアップ時にはkdumpの設定とdebuginfoの対応バージョンも合わせて確認するようにしてください。