kdumpで本番カーネルクラッシュを確実に採取する｜メモリ予約設計とcrashコマンドによる原因特定手順

本番サーバーがカーネルパニックを起こすと、再起動後に残るのはsyslogの断片だけ、というケースが今も後を絶ちません。kdumpはカーネルがクラッシュした瞬間に別カーネルを起動してメモリイメージをダンプするしくみであり、原因を「再現せずに特定する」唯一の手段です。しかし設定を誤るとダンプ自体が採れず、障害対応が長期化します。本記事では、crashkernel予約量の設計から、crashコマンドによる原因特定、2026年時点の主要ディストリビューションにおける差分まで、一連の運用シナリオを通して解説します。

なぜ本番環境でkdumpが必須になるのか

カーネルパニックは発生頻度こそ低いですが、発生した瞬間のメモリ状態を保存できなければ、原因の大半は「不明」で終わります。dmesgやkernelログはパニック直前の断片を拾えることもありますが、コールスタックの再構成やメモリ破壊箇所の特定には不十分です。特にドライバのバグ、NUMAアーキテクチャ上のメモリ破壊、RCUストールといった事象は、kdumpダンプがなければ再現試験を繰り返すしか手がなく、RTO（目標復旧時間）を大きく超過します。

2026年現在、RHEL 9・Ubuntu 24.04・Rocky Linux 9のいずれもkdumpをサポートしており、システムデプロイ時に有効化しておくことが運用のベースラインとして定着しつつあります。一方で、クラウドVM・コンテナホスト・ARMサーバーではメモリ予約量の設計を誤ると起動失敗やダンプ失敗が起きるため、環境ごとの調整が不可欠です。

crashkernelパラメータによるメモリ予約設計

kdumpの核心はキャプチャカーネル（第2カーネル）専用のメモリ領域を起動時に予約することです。この領域が小さすぎるとキャプチャカーネル自体が起動できず、大きすぎると本番ワークロードに影響します。

予約量の目安と設定例

RHEL 9およびRocky Linux 9では、インストーラが自動で crashkernel=auto を設定します。これはシステム搭載RAMに応じてカーネルが動的に予約量を決定する方式で、RAM 4 GB未満なら 160 MB、4 GB以上なら 256 MB前後が割り当てられます。一方、Ubuntu 24.04では crashkernel=512M のように固定値を推奨するケースが多く、ドキュメントでも明示値指定が基本とされています。

大容量RAM（512 GB以上）を搭載するDBサーバーでは auto が不足することがあります。現場では crashkernel=1G,high と crashkernel=256M,low を併用する「high/low分割指定」が採用されるケースも増えています。この構文はx86_64でのみ有効であり、GRUBに両行を追記したうえでgrub2-mkconfig（RHEL系）またはupdate-grub（Debian系）を実行します。

# /etc/default/grub の GRUB_CMDLINE_LINUX に追記する例（RHEL 9 / Rocky 9）
GRUB_CMDLINE_LINUX="... crashkernel=512M"

# 反映
sudo grub2-mkconfig -o /boot/grub2/grub.cfg

# Ubuntu 24.04 の場合
sudo update-grub

設定変更後は必ず再起動し、/proc/iomem | grep -i crash で予約アドレスが出力されることを確認します。何も出力されない場合は予約に失敗しています。

kdumpサービスの有効化と設定ファイルの要点

カーネルパラメータの設定が完了したら、kdumpデーモンを有効化します。RHEL 9・Rocky Linux 9では kdump.service が標準で含まれており、以下の手順で有効化できます。

sudo dnf install -y kexec-tools
sudo systemctl enable --now kdump.service
sudo systemctl status kdump.service

Ubuntu 24.04では linux-crashdump パッケージが対応します。

sudo apt install -y linux-crashdump
sudo systemctl enable --now kdump-tools.service

kdump.confの主要設定項目

RHEL系では /etc/kdump.conf が設定ファイルです。以下の点を環境に合わせて調整します。

• path: ダンプの保存先ディレクトリ。デフォルトは /var/crash。容量が潤沢な別パーティションやNFSマウントポイントを指定することを強く推奨します。
• core_collector makedumpfile: ダンプをフィルタリング・圧縮するコレクタ。-l --message-level 1 -d 31 はユーザー空間メモリを除外しながら高圧縮するオプションで、ダンプサイズを大幅に削減できます。
• default reboot: ダンプ採取後の動作。本番では reboot が一般的ですが、調査優先なら halt を選ぶケースもあります。

# /etc/kdump.conf の設定例
path /var/crash
core_collector makedumpfile -l --message-level 1 -d 31
default reboot

設定変更後は sudo systemctl restart kdump.service でinitramfsを再生成します。このステップを忘れると設定が反映されません。RHELではrestartの際にdracutが動作してキャプチャカーネル用initrdを更新するため、完了まで数十秒かかります。

動作確認：sysrqによるテストダンプの採取

本番環境でkdumpの動作を確認するには、意図的にカーネルパニックを発生させてダンプが採取されることを検証します。SysRqキーを使う方法が最も簡単で安全です。ただしサービスは停止するため、メンテナンスウィンドウ内で実施します。

# SysRq を有効化
echo 1 | sudo tee /proc/sys/kernel/sysrq

# カーネルパニックを発生させる（実行後すぐに再起動が始まります）
echo c | sudo tee /proc/sysrq-trigger

再起動後、/var/crash/ 配下にタイムスタンプ付きディレクトリが作成され、vmcore ファイルが存在することを確認します。ファイルが存在しない場合は、crashkernelの予約失敗・ストレージへの書き込みエラー・makedumpfileのオプション誤りのいずれかが原因として多く見られます。journalctl -u kdump.service と /var/log/kdump.log（存在する場合）を参照してください。

crashコマンドによる原因特定の手順

採取した vmcore は crash コマンドで解析します。crashはGDBベースのカーネルデバッガで、コールスタック・プロセス状態・カーネルメッセージリングバッファを対話的に調べられます。

# crash のインストール（RHEL系）
sudo dnf install -y crash kernel-debuginfo

# 解析開始（vmlinuxのパスはカーネルバージョンに合わせる）
sudo crash /usr/lib/debug/lib/modules/$(uname -r)/vmlinux /var/crash/$(ls /var/crash | tail -1)/vmcore

crashセッション内の主要コマンド

crashのプロンプトに入ったら、以下の順序で調査を進めるのが現場での定番手順です。

• log: カーネルのメッセージリングバッファを表示します。パニック直前の BUG: や Oops: の行がここに現れます。
• bt: パニック発生時のカーネルスタックトレースを表示します。どの関数呼び出しの連鎖がパニックに至ったかがわかります。
• ps: クラッシュ時点で実行中・待機中のプロセス一覧を表示します。RUN状態のプロセスが原因に関係していることが多いです。
• vm <pid>: 特定プロセスの仮想メモリマップを確認します。メモリ破壊系の障害で有効です。
• kmem -i: カーネルメモリの使用状況を表示します。OOM（Out of Memory）系の障害の切り分けに使います。

bt の出力でファンクション名が ??? になる場合は、debuginfoパッケージのバージョンがvmcoreと一致していません。crash-utility や kernel-debuginfo のバージョンをvmcore採取時のカーネルバージョンに揃え直す必要があります。このズレはカーネルアップデート後にダンプを再解析しようとするときに頻発するため注意が必要です。

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

2026年時点で主流となっている環境では、以下の点が従来の手順と異なります。運用手順書を最新化する際の参考にしてください。

RHEL 9 / Rocky Linux 9 系

RHEL 9ではkdumpの設定UIが kdumpctl コマンドに統合されています。kdumpctl estimate を実行するとシステム構成に基づく推奨crashkernel値が出力されるため、予約量の見積もりに活用できます。また、RHEL 9.4以降ではfadump（Firmware Assisted Dump）をIBM POWER環境で優先的に使用するよう設定が変わっており、x86_64とPOWERで設定ファイルの分岐が必要です。

Ubuntu 22.04 / 24.04 系

Ubuntu 22.04以降では linux-crashdump メタパッケージが kdump-tools を依存として引き込みます。設定ファイルは /etc/default/kdump-tools であり、RHEL系の /etc/kdump.conf とは異なります。Ubuntu 24.04ではsecure boot環境でのkdump署名要件が厳しくなっており、カスタムカーネルを使用している場合はダンプ用initrdへの署名が別途必要になるケースがあります。

クラウドVM・コンテナホストでの注意

AWSのEC2（Nitroインスタンス）やAzure VM Bシリーズなど、小メモリインスタンスでは crashkernel=auto が要求する予約量を確保できずkdumpサービスが起動失敗する事例が報告されています。インスタンスタイプの変更が難しい場合は、crashkernel=128M まで下げて最低限の採取を狙う運用も選択肢のひとつです。ただしキャプチャカーネルの起動保証はなく、採取できない場合があることを許容したうえで設定します。コンテナホスト（Kubernetes node）では、ホストカーネルに対してkdumpを設定すれば全コンテナのクラッシュを拾えますが、ダンプサイズが数十GBになりうるため保存先の容量設計が特に重要です。

kdumpは「設定した」で終わりではなく、定期的なテストダンプ採取と保存先の空き容量監視をセットで運用することが、本番クラッシュ時の確実な採取につながります。モニタリングツールから /var/crash の使用量アラートを設定しておくと、ディスクフルによるダンプ失敗を未然に防げます。