クイックスタート：5分で完了するkdumpのセットアップ
原因不明のシステムクラッシュから本番サーバーを直ちに保護する必要がある場合は、次の3つのステップを順に実行してください。
ステップ1：kexec-toolsパッケージのインストール
ターミナルを開き、カーネルロードを制御するパッケージをインストールします：
sudo dnf install -y kexec-toolsステップ2：クラッシュカーネル専用メモリの確保
レスキューカーネルは、メインシステムがクラッシュした際に動作するための独立したメモリ領域を必要とします。grubbyを使用してブートパラメータを設定します：
sudo grubby --update-kernel=ALL --args="crashkernel=512M"サーバーを再起動して、GRUBにこのメモリ予約設定を適用させます：
sudo rebootステップ3：サービスの有効化とステータス確認
システムの起動が完了したら、kdumpデーモンを有効化して起動します：
sudo systemctl enable --now kdump.service
sudo kdumpctl statuskdump: Kdump is operationalという結果が返ってくれば、システムはいつでもクラッシュログを記録できる状態になっています。
Kernel Panic発生時、kdumpはどのように動作するのか？
Kernel Panicが発生すると、すべてのCPUは通常のタスク処理を停止し、RAM上のメモリはフリーズします。rsyslogやsystemd-journaldといった従来のロギングプロセスは完全に麻痺するため、再起動後の/var/log/messagesには何の手がかりも残りません。
そこで登場するのがkdumpです。kdumpは独立したブラックボックスのように機能します。kexecの仕組みを利用して、あらかじめ隔離しておいた512MBのメモリ領域に軽量なレスキューカーネル（capture kernel）を即座にロードします。このプロセス全体において、時間のかかるBIOS/UEFIのハードウェア初期化チェックはスキップされます。
capture kernelの役割は極めてシンプルです。旧カーネルのRAMデータをすべて抽出し、vmcoreファイルとして圧縮してディスクに書き込みます。書き込みが完了すると、システムは自動的に再起動します。
実運用の現場では、サードパーティ製ネットワークドライバを使用して高負荷な計算サービスを稼働させているFedoraサーバー群などで、メモリ破壊（memory corruption）や潜在的なデッドロックが発生しがちです。vmcoreがなければ、何百ものコミット履歴を当て推量で調査するか、無駄にハードウェアを交換し続けるしかなくなってしまいます。
kdump.confの詳細設定とチューニング
メイン設定ファイルは/etc/kdump.confにあります。デフォルトではローカルディスクにダンプが保存されますが、インフラ環境に合わせて柔軟に変更できます。
1. 保存先ストレージの変更
ルートパーティション（/）に直接ダンプを書き込むと、ディスク容量を圧迫して枯渇させるリスクがあります。専用のデータパーティションや、ネットワーク経由のNFSサーバーにパスを変更することが推奨されます：
# /mnt/crash にマウントされた専用パーティションに保存
path /mnt/crash
# または内部ネットワーク上のNFSサーバーに転送
# nfs 192.168.1.50:/data/kdumps2. makedumpfileによるダンプファイルサイズの圧縮・削減
64GBや128GBのRAMを搭載したサーバーで生データ（生ダンプ）をそのまま書き込むと、膨大なディスク領域を消費するだけでなく、保存に十数分もかかってしまいます。以下の設定により、圧縮前に不要なデータをフィルタリングして除外できます：
core_collector makedumpfile -l --message-level 7 -d 31-d 31オプションは、すべてのフィルタフラグを有効にすることを意味します。ゼロページ、キャッシュ、ユーザ空間アプリケーションのデータ、およびフリーページを除外し、カーネルのデータ構造のみをダンプファイルに残します。これにより、ファイルサイズを64GBからわずか600MB〜1.2GB程度にまで劇的に削減できます。
実践：制御されたパニックの誘発とダンプ解析
実際の障害が発生してからkdumpのメモリ不足などの設定ミスに気づくのでは遅すぎます。ステージング環境で事前にパニックを意図的に発生させ、動作検証を行いましょう。
SysRqを使用した疑似Kernel Panicの発生
LinuxカーネルはMagic SysRqを介した直接制御をサポートしています。以下の2つのコマンドを実行します（※実行すると即座にシステムがクラッシュして再起動するため注意してください）：
echo 1 | sudo tee /proc/sys/kernel/sysrq
echo c | sudo tee /proc/sysrq-triggerシステムの再起動が完了したら、クラッシュファイルが保存されているディレクトリを確認します：
ls -lh /var/crash/127.0.0.1-YYYY-MM-DD-HH:MM:SS/という形式のディレクトリが作成され、その中にvmcoreファイルとクラッシュ時のdmesgログをまとめたテキストファイルが生成されていることが確認できます。
crashユーティリティによるvmcoreの解析
このバイナリファイルを解析するには、crashツールと、クラッシュしたカーネルバージョンに正確に一致するデバッグシンボル（debuginfo）をインストールする必要があります：
sudo dnf install -y crash dnf-plugins-core
sudo dnf debuginfo-install -y kernel-$(uname -r)解析ツールを起動します：
crash /usr/lib/debug/lib/modules/$(uname -r)/vmlinux /var/crash/127.0.0.1-*/vmcoreプロンプトcrash>が表示されたら、bt（backtrace）コマンドを入力して関数呼び出しのコールスタックをトレースします：
crash> bt
PID: 1420 TASK: ffff88012a45c000 CPU: 1 COMMAND: "tee"
#0 [ffffc90001423d60] machine_kexec at ffffffff8106a3f3
#1 [ffffc90001423dc0] __crash_kexec at ffffffff8116248d
#2 [ffffc90001423e80] panic at ffffffff810be512
#3 [ffffc90001423f00] sysrq_handle_crash at ffffffff81580125
#4 [ffffc90001423f10] __handle_sysrq at ffffffff81580872スタックトレースから、teeプロセス（PID 1420）がクラッシュを誘発する関数sysrq_handle_crashを呼び出したことが明確に読み取れます。実際の障害発生時には、このコールスタックが不具合の原因となっているサードパーティドライバ名や、ポインタの不正参照を起こしたカーネル関数をピンポイントで特定してくれます。稼働中のシステムの詳細な調査には、eBPFによるLinuxパフォーマンス分析とトラブルシューティングツールの併用も効果的です。
実運用における注意点
- crashkernelのメモリ割り当て量：
512Mの設定は、8GB〜32GBのRAMを搭載したサーバーに最適です。128GB以上のRAMを搭載し、ブート時に巨大なドライバを多数読み込むRAIDカードや10GbE/25GbE光ネットワークカードを備えたサーバーでは、レスキューカーネルのOOM（Out of Memory）を防ぐため、768Mまたは1024Mに引き上げることをおすすめします。 - 自動クリーンアップ：1つの
vmcoreファイルは1GB〜2GBのディスク容量を消費することがあります。クラッシュが連続して発生すると/var領域が枯渇する恐れがあるため、systemd-tmpfilesやcronジョブを設定して、14日以上経過した古いクラッシュディレクトリを定期的に削除するようにしてください。 - カーネル更新時の注意：
dnf upgradeでカーネルを新しいバージョンに更新した際は、sudo kdumpctl statusを実行し、dracutによって互換性のあるレスキュー用ramdiskが正常に再生成されているかを必ず確認してください。
