kdump を使用した Linux クラッシュダンプの保存と分析

カーネルのクラッシュ時にkdumpが記録する内容

kdump は、クラッシュが発生する前に Linux カーネルのメモリイメージのバックアップ準備を行います。そのため、通常のカーネルの起動時にメモリ領域が確保されます。この領域には、別の キャプチャカーネル 読み込まれており、適切なクラッシュ発生時にkexecを介して起動される。

キャプチャカーネルは、クラッシュしたシステムカーネルとは独立して動作し、 /proc/vmcore. このイメージを、設定済みの保存先に書き出すことができます。保存されたファイルは通常「vmcore」と呼ばれますが、元のメモリ領域がすべて含まれているかどうかは、選択したフィルタリング設定などによって異なります。

それぞれの役割は分かれています。kdumpはシステムの状態をキャプチャしてバックアップする一方、プログラムは クラッシュ その後、既存のダンプを解析します。これにより、カーネルメッセージやタスクスタックなどを調査することができます。なお、ダンプは特定の時点のスナップショットであり、エラーに至るまでの完全な経緯を自動的に提供するものではありません。

カーネル・オオプスとカーネル・パニックは同義ではありません。オオプスは、システムが直ちにパニック状態に移行することなく発生する場合があります。そのため、すべてのカーネル障害がkdumpによる記録につながるわけではありません。一方、アプリケーションのコアダンプはプロセスの状態に関するものであり、カーネルのvmcoreではありません。

事後調査において、この準備は極めて重要です。クラッシュ発生時にキャプチャカーネルが準備されていなかった場合、あるいはイメージが保存されていなかった場合、kdumpは失われたメモリ状態を後から復元することができません。その場合、既存のログや再起動後に保持されたその他の診断データが、調査の出発点となります。

収集の前提条件と制限

まず、サーバーのディストリビューション、バージョン、アーキテクチャを確認してください。これらによって、パッケージ名、サービス管理、ブート設定、およびサポートされるストレージ先が決まります。セットアップの際は、さまざまなディストリビューションのコマンドを組み合わせるのではなく、そのプラットフォーム固有のドキュメントを参照してください。また、ハードウェアやインストールされているドライバも要件に影響を与えます。

ブートパラメータ crashkernel は メモリの予約 クラッシュ記録用に確保します。この領域は通常の運用では利用できません。一律のサイズを設定するのは信頼性が低いため、ディストリビューション、アーキテクチャ、具体的な構成に関する仕様に基づき、キャプチャシステムのストレージ要件も考慮して設定してください。

予約されたメモリだけでは不十分です。キャプチャカーネルがロードされており、設定された宛先に到達できる必要があります。そのためには、その環境に必要なドライバやコンポーネントが利用可能である必要があります。ネットワーク宛先の場合は、接続と到達可能な相手先も前提条件に含まれます。

宛先には、予想されるイメージとその保存に必要な十分な容量を確保してください。ダンプのサイズは、ストレージの内容やフィルタリングなどの要因によって異なります。宛先が満杯であるか、またはアクセスできない場合、予約が正しく設定されていてもバックアップが実行されない可能性があります。

あらかじめ準備されたインストール環境であっても、利用可能なダンプが得られる保証はありません。 「Oops」が必ずしも「Panic」を引き起こすとは限りません。電源が完全に失われると、キャプチャカーネルは動作しなくなります。同様に、深刻なハードウェア障害により、起動やイメージの書き込みが妨げられることもあります。したがって、キャプチャとターゲットについては、実際のエラーの原因とは別個に検討する必要があります。

分析の対象となるファイル

調査には、ダンプファイルだけでなく、関連するカーネルファイルやログも可能な限り保存しておくことが重要です。そうすることで、クラッシュ時の状態を、メッセージや変更内容と照合できるようになります。以下の概要では、実際のメモリイメージと、その解析を可能にする補助ファイルとを区別しています。

特に重要なのは、 適切な vmlinux: アーキテクチャと正確なカーネルビルドは、クラッシュしたシステムカーネルに属している必要があります。再起動後に実行されるカーネルは、それとは異なるものでも構いません。 uname -r そのため、再起動したサーバー上では、古いダンプに対応する正しいファイルを選択するには不十分です。

また、カーネルおよびダンプ形式と互換性のあるバージョンのcrashを使用してください。外部ドライバや追加ドライバが関係している場合は、それらに対応するモジュールファイルやデバッグ情報も用意しておいてください。 シンボルが欠落していたり、必要なメモリページが除外されていたりする場合、解析結果が不完全になる可能性があります。こうした不備については、調査結果の報告書に記載してください。

vmcore には、メモリ内の機密情報が含まれている可能性があります。そのため、アクセスを制限し、転送を保護するとともに、保存期間および削除期限を定めてください。 ダンプや補足ログをサポートサービスに提供する前に、必要な承認と許容される範囲について確認してください。

サーバー上でkdumpの準備を行う

出発点は、サーバーのディストリビューション、バージョン、およびアーキテクチャです。 各ディストリビューションのドキュメントを参照し、kdump およびキャプチャカーネルの読み込みに必要なパッケージや、サービスの設定方法を確認してください。ディストリビューションごとの手順は互いに置き換え可能ではありません。パッケージ名、ブート設定、検証ツールなどが異なる場合があります。

準備には、適切な メモリの予約 ブートパラメータについて crashkernel. 具体的なプラットフォームやハードウェアの仕様に基づいて、サイズや、必要に応じてその他の設定を選択してください。予約されたメモリは通常動作中のシステムからは利用できないため、一律のサイズ指定は役に立たないだけでなく、他のサーバーからの設定を検証せずにそのまま適用することも同様に避けるべきです。

プラットフォーム固有のブート設定を行い、必要に応じて再起動した後、以下の読み取り専用シェルコマンドを実行すると、現在実行中のカーネルのパラメータが表示されます。出力の中から以下を探してください。 crashkernel. エントリには渡された設定が表示されますが、キャプチャカーネルが読み込まれたことや、バックアップが正常に完了したことを証明するものではありません。

cat /proc/cmdline

RHEL 9 では、シェルで次のコマンドを実行してステータスを確認することもできます。他のディストリビューションでは、そのディストリビューションのドキュメントに記載されている確認方法を使用してください。陽性 ステータスメッセージ これは重要な指標ではありますが、セキュリティプロセス全体に対する厳格なテストに代わるものではありません。

kdumpctl status

また、想定されているターゲットと、それに必要なドライバがキャプチャシステムで利用可能かどうかを確認してください。 選択した設定と確認日時を記録しておき、カーネルやインフラストラクチャの変更後に再評価できるようにしてください。具体的な設定については、本番環境での運用前に、実際に使用されるターゲットプラットフォームで検証する必要があります。

バックアップ対象とダンプ範囲の選択

仝 保全目標 データ収集中はアクセス可能であり、十分な空き容量を確保しておく必要があります。ローカル先を選択すればネットワーク接続への依存を回避できますが、サーバー上に利用可能なストレージ容量が必要となります。また、保存されたダンプや付随する診断ファイルが複数のファイルとなり、容量を消費する可能性があることも考慮に入れておいてください。

RHEL 9 では、ローカルなターゲットに加え、NFS や SSH 経由のネットワーク上のターゲットについてもドキュメント化されています。これにより、ファイルを対象のサーバーとは別の場所に保存することが可能ですが、その場合は、ネットワーク、相手先、およびキャプチャシステム内の必要なコンポーネントが正常に動作している必要があります。 通常の運用環境での到達可能性をキャプチャシステムでの到達可能性と同一視するのではなく、具体的なRHEL構成におけるそれぞれの制限事項を確認してください。

と一緒に makedumpfile この画像を圧縮し、選択したメモリ領域に基づいてフィルタリングすることができます。 フィルタリング ストレージ容量や転送量を節約できますが、後々の調査で必要となる可能性のあるページが削除されてしまう場合があります。そのため、ダンプの範囲は予想される診断内容に合わせて設定し、使用したフィルタを記録しておいてください。ファイルサイズが最も小さいものが、必ずしも最も有用であるとは限りません。

vmcore には、メモリ内の機密情報が含まれている可能性があります。そのため、アクセスを制限し、転送を保護するとともに、ファイルの保存期間や削除時期を明確に定めてください。 サポートサービスに提供するには、事前に必要な承認を得てください。これは、別途保存されたコピーについても同様です。

クラッシュ時に生成された既存のvmcoreを開く

事後分析を行うには、既存のvmcoreと、クラッシュしたカーネルのビルドおよびアーキテクチャに適合する デバッグ情報を含むvmlinux また、カーネルおよびダンプ形式と互換性のあるcrashのバージョンも必要です。再起動後に動作するカーネルは異なる場合があるため、そのバージョン情報だけでは、クラッシュしたビルドを確実に特定することはできません。

以下のコマンド例は、解析システムの通常のシェルで実行するものです。両方のパスは、実際に存在するファイルのパスに置き換えてください。このコマンドは、解析用に既存のイメージを開くものであり、ダンプを作成したり、kdumpを設定したりすることはありません。

crash /pfad/zum/passenden/vmlinux /pfad/zum/vmcore

順調なスタートを切った後、あなたは以下の業務に取り組みます。 crash-Prompt, 通常のシェルではもう表示されません。そこでは log 利用可能なカーネルメッセージ。まずはパニックメッセージとその発生前後の状況を確認してください。メッセージは手がかりとなる場合がありますが、必ずしも完全な原因を説明しているとは限りません。

と一緒に bt 現在の解析コンテキストのスタックを調査します； bt -a CPU上のアクティブなタスクのスタックを表示します。単一のフレームを原因の証拠として扱うのではなく、呼び出しチェーンとメッセージを照らし合わせて確認してください。ダンプの状態や範囲によっては、情報が欠落している場合があります。

同じプロンプト内で役立つのは ps タスクの一覧画面で； kmem -i メモリに関する一般的な情報を提供します。このスナップショットだけでは、メモリリークそのものやその原因を証明するものではありません。関係するモジュールをさらに詳細に調査する場合は、該当するモジュールファイルやデバッグ情報も追加で必要になる場合があります。

スタックとメモリに関する注意事項の整理

ドライバの変更後にパニックが発生した場合は、まずその発生時刻、クラッシュしたカーネルのビルド、および関連するモジュールを記録しておいてください。 これらの情報を変更履歴と照らし合わせてください。ドライバのみが更新されたのか、それとも同時に新しいカーネルもインストールされたのか？ これにより、調査に関連する変更を絞り込むことができます。

その後、以下を読んでください log 利用可能なカーネルメッセージを確認し、 bt 現在の解析コンテキストのスタック。 bt -a CPUのアクティブなタスクに関する情報を補足します。パニックのメッセージに加え、パニックが発生する直前のメッセージも記録しておいてください。それらは、後で発生するエラーの背景情報を提供する可能性があります。

A ドライバフレーム スタックには手がかりはありますが、原因の決定的な証拠にはなりません。例えば、以前に発生したメモリの破損が、ドライバ関数内で初めて顕在化する場合もあります。したがって、変更が原因であると断定する前に、メッセージ、関連するモジュール、および処理の流れが整合しているかどうかを確認してください。

記憶の疑いがある場合、以下の情報が提供されます kmem -i ダンプおよびツールが提供する範囲でのメモリ情報の概要です。これらの値は、カーネルメッセージと併せて確認してください。個々の値だけでは、メモリリークの有無やその原因を特定することはできません。また、フィルタリングによって必要なメモリページが欠落している可能性もあります。

消費量が時間の経過とともに増加するかどうかを判断するには、追加の時系列データが必要となります。CPU負荷を個別に調査する場合、 LinuxのPerfツールを使ったCPUプロファイリング 役立つ。このような測定結果はクラッシュダンプを補完するものではあるが、クラッシュ発生時点の状態を記録したクラッシュダンプに取って代わるものではない。

利用可能なvmcoreが存在しない場合

フリーズ後に再起動した場合、まずパニックが発生したかどうか、そしてvmcoreが保存されたかどうかを確認する必要があります。再起動しただけでは、そのどちらの事実も証明されません。ファイルが存在しないことを理由に特定のエラーを結論づける前に、発生時刻と一致するログメッセージや、設定された保存先を確認してください。

次のことを調査してください 追跡チェーン 補足：問題のボートにキャプチャカーネルが読み込まれていたか、またその事象はkdumpを起動させるのに適していたか？すべての「Oops」がパニックにつながるわけではない。また、完全な電源喪失や重大なハードウェア障害により、キャプチャカーネルの起動やデータ書き込みが妨げられる場合もある。

その後、バックアップ先を確認してください。アクセス可能だったか、十分な空き容量があったか、そしてキャプチャシステムに必要なドライバやコンポーネントが含まれていたかを確認します。ネットワーク先の場合は、接続や相手側システムといった依存関係も考慮する必要があります。RHELでは、ファイル kexec-dmesg.log 作成・保存されている場合は、収集フェーズに関する情報を記載する。

利用可能なダンプがない場合、以前のジャーナルや、コンソールおよびカーネルからの永続的なメッセージが重要な代替手段となります。ただし、これらの情報源からは完全なメモリイメージは得られず、失われた状態を後からkdumpを使って復元することはできません。

報告やその他の観察結果からネットワークの問題が示唆される場合、追加の LinuxのSoftIRQ使用率の分析 パッケージ処理の分類に役立ちます。これは、ダンプ先の検証とは異なる疑問に答えるものであり、それ自体ではパニックの発生やバックアップ失敗の原因を証明するものではありません。

データ収集のテストと結果の検証

ダンプの範囲は、予想される診断上の疑問点と利用可能なリソースに基づいて選択してください。圧縮やフィルタリングを行うことで、ストレージ容量や転送量を節約できますが、削除されたメモリページは後の調査では利用できなくなります。どのデータが欠落している可能性があるかが分析時に把握できるよう、この決定内容を記録しておいてください。

vmcore には機密性の高いメモリ内容が含まれている可能性があります。そのため、アクセス、安全な転送、保存期間、および関連するデバッグファイルの保管について適切に管理してください。サポートサービスに提供するには、事前に必要な承認とデータの取り扱い方針を確認してください。

カーネル、ドライバ、ブート設定、またはバックアップインフラストラクチャに変更があった場合は、準備状況を再度確認してください。これには、ロードされたキャプチャカーネルや、選択したターゲットへの到達可能性などが含まれます。 ステータスメッセージが「成功」と表示されても、現在の条件下で実際に分析可能なダンプが生成されるかどうかは、それだけでは判断できません。

警告： 制御されたエンドツーエンドテストでは、意図的にクラッシュを発生させるため、再起動やデータ損失を引き起こす可能性があります。 このテストは、承認済みのテスト環境、またはデータバックアップが実施された状態で事前に準備されたメンテナンスウィンドウ内でのみ実行してください。事前に責任の所在、影響範囲、および復旧手順を明確にしておいてください。なお、このテストでは、意図的にトリガーコマンドは指定されていません。

説得力のある エンドツーエンドテスト ステータス確認だけで終わらせないでください。ファイルが指定された宛先に正常に届いているか、また、記録されたビルドに対応するファイルとして正常に開けるかを確認してください。 その後、サーバーのデバッグを行う際には、発見事項、不足しているデータ、不確実な点、および次の検証手順を記録してください。その際、観察された兆候と、まだ確認されていない原因とは明確に区別してください。