kdumpで本番カーネルパニックの原因を特定する｜crashカーネル設定からコアダンプ解析と再発判断まで

本番環境でカーネルパニックが起きると、サーバーは再起動するだけで原因の痕跡をほとんど残しません。syslogに断片的な記録が残ることもありますが、それだけでは根本原因の特定には不十分なケースが大半です。こうした状況で有効なのがkdumpです。パニック発生時にメモリの内容をそのまま別カーネルでダンプとして書き出し、後から詳細を解析できます。本記事では、crashカーネルの設定・動作確認・解析コマンド・再発判断の流れを一本で完結させます。

kdumpが必要になる場面と仕組みの概要

カーネルパニックは、ハードウェア障害・ドライバのバグ・メモリ破壊・OOMキラーの誤動作など、さまざまな要因で発生します。再現性が低く、「再起動したら直った」で終わらせてしまうと、同じ障害が本番で繰り返されるリスクが残ります。

kdumpの仕組みは二段階です。まず通常起動時に、物理メモリの一部をクラッシュカーネル用に予約します（crashkernel パラメータ）。パニックが発生すると、kexecの仕組みでその予約済み領域にあらかじめ配置しておいた小型の「クラッシュカーネル」が即座に起動します。このクラッシュカーネルがメインメモリの内容をコアダンプファイルとして書き出し、完了後に通常再起動へ移行します。運用者は書き出されたダンプをcrashコマンドで解析し、パニック直前のコールスタックや原因箇所を特定できます。

crashカーネルの設定と有効化

2026年現在、主要ディストリビューションでのkdump設定方法は以下のとおりです。RHELおよびAlmaLinux・Rocky Linux系はkdumpサービスがあらかじめ用意されており、比較的スムーズに設定できます。

RHEL系（AlmaLinux 9 / Rocky Linux 9）での設定例：

# crashkernelパラメータをGRUBに追加
grubby --update-kernel=ALL --args="crashkernel=auto"

# kdumpサービスを有効化・起動
systemctl enable --now kdump

# 再起動して予約メモリを反映
reboot

crashkernel=auto は搭載メモリに応じて適切なサイズを自動決定します。マシンの物理メモリが2GB以上ある場合は auto を使うのが現在の推奨です。手動で指定する場合は crashkernel=256M のように書きます。予約サイズが不足するとダンプ取得中にクラッシュカーネル自体がOOMになるため、物理メモリが多いサーバーでは crashkernel=512M 以上を検討してください。

Ubuntu 22.04 / 24.04 LTS での設定例：

# linux-crashdump メタパッケージをインストール
apt install linux-crashdump

# kdump-toolsを有効化
# /etc/default/kdump-tools の USE_KDUMP=1 を確認
systemctl enable --now kdump-tools

# GRUBのcrashkernelパラメータ確認
grep crashkernel /proc/cmdline

設定後に /proc/cmdline で crashkernel= が含まれること、/sys/kernel/kexec_crash_loaded の値が 1 であることを確認してください。0 のままであれば、クラッシュカーネルがロードされておらず、パニック発生時にダンプは取得されません。

動作確認：安全なパニックテストの手順

本番環境でいきなりパニックテストを実施することは推奨されませんが、検証環境や本番への投入前には必ず動作を確認しておく必要があります。意図的にパニックを発生させるには、sysrq を使います。

# sysrqを一時的に有効化
echo 1 > /proc/sys/kernel/sysrq

# パニックを発生させる（注意：即時カーネルクラッシュが起こります）
echo c > /proc/sysrq-trigger

このコマンドを実行すると、カーネルは即座にクラッシュし、クラッシュカーネルが起動してダンプを取得します。完了後、サーバーは自動的に再起動します。ダンプは通常 /var/crash/ または /var/kdump/ 以下に配置されます（ディストリビューションにより異なります）。RHEL系は /etc/kdump.conf の path ディレクティブで変更可能です。

現場では、本番投入前に同スペックの検証機でこのテストを行い、ダンプが正常に取得されることを確認する運用が一般的になっています。

crashコマンドによるコアダンプ解析

ダンプが取得できたら、crashコマンドで解析します。crashはカーネルデバッグシンボル（vmlinux）とダンプファイルを組み合わせて使用します。

# RHEL系でcrashツールをインストール
dnf install crash

# Ubuntuの場合
apt install crash

# デバッグシンボルパッケージの取得（RHEL系）
dnf install kernel-debuginfo

# crashの起動
crash /usr/lib/debug/lib/modules/$(uname -r)/vmlinux \
      /var/crash/127.0.0.1-<日時>/vmcore

起動後、対話型プロンプトで以下のコマンドを順に実行するのが基本の流れです。

• bt（backtrace）：パニック発生時のコールスタックを表示します。どの関数でクラッシュが起きたかが一目で分かります。
• log：カーネルのリングバッファ（dmesg相当）を表示します。パニック直前のメッセージを確認できます。
• ps：クラッシュ時点で動作していたプロセス一覧を表示します。特定プロセスが原因かどうかの絞り込みに使います。
• vm <pid>：特定プロセスの仮想メモリマップを確認します。メモリ破壊の調査に有効です。
• kmem -i：メモリ使用状況のサマリを表示します。OOM起因の可能性を評価するときに参照します。

実際の解析では、btで表示されたコールスタックの最上位にある関数名をカーネルのソースコードや既知のバグトラッカーと照合します。たとえば、ネットワークドライバのモジュール名が連続して現れるケースでは、ドライバのバグや非互換ファームウェアが疑われます。logに「Call Trace」以前のメッセージとして「BUG: unable to handle kernel paging request」や「general protection fault」といった行があれば、どのメモリアクセスで問題が起きたかも特定の手がかりになります。

再発判断と対処の進め方

解析で原因箇所が特定できたら、次は再発リスクの評価と対処方針の決定です。以下の観点で判断します。

• ハードウェア起因か否か：MCEログ（mcelogやrasdaemon）にメモリエラーやCPUエラーが記録されていれば、ハードウェアの交換を検討します。ソフトウェア要因との切り分けが最初のステップです。
• 既知のカーネルバグか否か：コールスタックに含まれる関数名とカーネルバージョンで、Red Hat Bugzilla・Ubuntu Launchpad・kernel.org のChangeLogを確認します。パッチ適用済みのバージョンにアップグレードするだけで解決するケースも多くあります。
• 特定モジュールの問題か否か：問題のモジュールをアンロードまたは代替モジュールへ切り替えることで、ワークアラウンドとして再発を防げる場合があります。
• 再発頻度と業務影響の評価：同じ条件でしか再発しない単発事象なのか、定期的に起きているのかを確認します。kdumpのダンプが複数ある場合は、btの結果を比較して同一原因かどうかを判断します。

原因が特定できず再発の可能性が残る場合、一時的な対処としてはカーネルの panic_on_oops と panic パラメータを調整してダンプ取得機会を増やしつつ、監視アラートの閾値を下げてリソース異常を早期検知する体制を整えることが現場では一般的です。

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

kdumpを取り巻く環境は、ここ数年で変化が続いています。2026年時点で特に注意が必要な差分をまとめます。

RHEL 9系（AlmaLinux 9 / Rocky Linux 9）：kdumpサービスはsystemdユニットとして統合されており、従来の /etc/init.d/kdump は存在しません。kdumpctl コマンドが使えるため、kdumpctl start で即時テスト起動が可能です。また、crashkernel=auto の動作が改善され、小メモリ環境でも適切なサイズが選択されるようになっています。

Ubuntu 24.04 LTS：kdump-toolsパッケージが引き続き利用可能ですが、secureboot環境ではクラッシュカーネルのロードに署名済みシムが必要になるケースがあります。/sys/kernel/kexec_crash_loaded が 0 のままになっている場合、securebootの制約が原因である可能性を疑ってください。

クラウド・仮想環境での注意：AWS EC2やGoogle Compute EngineなどのパブリッククラウドVMでは、インスタンスタイプによってkdumpが正常に機能しない場合があります。特に、クラッシュカーネル起動後のデバイス認識でストレージが見えなくなるケースが報告されており、ダンプの保存先をNFSや別ホストのSSHに変更することで回避できます。/etc/kdump.conf に ssh user@remote-host を指定することで、ネットワーク越しにダンプを書き出せます。

ARM64（aarch64）環境：Raspberry PiやAmpere系サーバーでLinuxを運用する環境が増えていますが、ARM64でのkdumpはカーネル4.20以降で安定してきました。2026年現在、AlmaLinux 9のaarch64ビルドではkdumpが標準サポートされています。ただし、crashkernel のサイズ調整が必要になるケースがx86_64より多いため、テスト時に余裕を持ったサイズ指定を検討してください。

kdumpは設定して終わりではなく、定期的に /sys/kernel/kexec_crash_loaded を監視に組み込み、カーネルアップデート後に再確認するサイクルを運用プロセスに組み込むことが、本番障害への備えとして重要です。