- Kdumpはダンプ用にkexec経由でキャプチャカーネルを予約する
vmcoreパニックになった後。 - クラッシュや重複を避けるために、crashkernel とダンプ パスを適切に構成します。
- セキュア ブートと連続スロットの欠如は、kdump をロードするときに最もよく発生するエラーです。
- クラッシュを使用する
vmlinuxとともに シンボル 詳細かつ信頼性の高い分析を実現します。
Linuxシステムでカーネルパニックが発生した場合（カーネルパニックとシステムクラッシュの違いを参照）、唯一信頼できる手がかりは通常、カーネルメモリダンプです。kdumpを設定し、crashコマンドでvmcoreを分析することで、特にログに痕跡が残っていない場合でも、何が起こったのかを推測するのではなく、正確に診断することができます。
この実践的なガイドでは、この分野における最高の技術情報源から重要なポイントを厳選し、明確なロードマップを提供します。具体的には、kdumpとは何か、よくある落とし穴を避けて設定する方法、典型的なエラー（セキュアブート、カーネルクラッシュ、保存パスなど）を解決する方法、そしてクラッシュを利用してvmcoreを調査する方法などを解説します。システムが1日に何度もクラッシュする場合、このガイドは現実的かつ詳細なアクションプランを提供し、システムを正常な状態に戻すのに役立ちます。
kdump と crash とは何ですか? なぜ重要なのですか?
kdump 機能は、壊滅的な障害が発生した場合にカーネル ダンプ メカニズムを有効にします。 Kdumpは2番目のキャプチャカーネル用のメモリを予約します システムコールによって開始される kexec メインカーネルがパニックを起こし、そこから停止したシステムのメモリをディスクにダンプします。
多くのエンタープライズ向け配布イメージでは、イメージの日付に応じて、クラッシュダンプを生成するようにシステムが部分的に、または完全に構成されています。それでも、ダンプが正しい場所に生成および保存されるように、構成を確認して完了させることをお勧めします。
Red Hat のクラッシュ ツールは、カーネル ダンプ分析の事実上の標準です。 Crashを使用すると、kdump、makedumpfile、diskdumpなどで取得したダンプを検査できます。、そして実行中のシステムでも動作可能です。 /dev/mem あるいは、Red Hatの派生製品では、 /dev/crashgdbを使用するよりも強力です /proc/kcore 内部カーネル構造へのアクセスの制限と適切なバイナリの要件のためです。
Red Hatは、特に重要な環境においては、管理者が通常のカーネル更新サイクル内でkexec-toolsを定期的に更新およびテストすることを推奨します。新しいカーネル機能がリリースされた際には、なおさら頻繁に更新およびテストを行うことが重要です。この習慣により、システムの可用性が脅かされるような状況での予期せぬトラブルを軽減できます。
正しい構成とダンプパス
まず、どのようなファイルが取得されるかを理解しましょう。典型的なダンプでは、少なくとも以下のファイルが表示されます。 vmcore カーネルメモリ付き および補助ファイル vmcore-dmesg.txt o kexec-dmesg.logクラッシュ前の通話やメッセージのコンテキストを再構築するのに役立ちます。
ダンプの保存場所を明確に定義することが重要です。ダンプの保存先をマウントするシステムでは、典型的なケースとして、 /var/crash 意図せずして、 スタイルのネストされたルート /var/crash/var/crashこれはファイルシステムがマウントされているときに発生します。 /var/crash そしてまた /etc/kdump.conf 確立されています path /var/crashその結果、ダンプはその重複パスに該当します。
解決策は簡単です。ダンプマウントポイントがすでに /var/crashは、定義します kdump.conf path / 代わりに path /var/crashこうすることでネストが回避され、ダンプは期待通りのディレクトリに表示されます。設定ファイルのフィルター（コメントと空行は無視）を使用して、有効なオプションが出力先の実際のマウントと一致するようにしてください。
GRUBを搭載したディストリビューションでは、キャプチャカーネルのメモリ割り当てはパラメータで設定されます。 crashkernel= の行で ブーツ次のような値をテストするのが一般的です。 crashkernel=128M, 256M, 512M o auto、構成を再生成します grub2-mkconfig o update-grub しかし、ディストリビューションのファミリーによると、メモリを予約するだけでは、他のクラッシュが発生した場合にサービスが開始されることを保証するものではありません。
Ubuntu/Debian環境では、典型的な手順はパッケージをインストールすることです。 linux-crashdump, サービスを有効にする kdump-tools 調整します /etc/default/grub パラメータ付き crashkernel= 前に update-grub。 コマンド kdump-config show ステータスが表示されます: ダンプディレクトリ (/var/crash), リンク先 vmlinuz e initrd キャプチャカーネルから、予約済みアドレス、そしてkdumpを実行する準備ができているかどうかを確認します。「現在の状態: kdumpを実行する準備ができていません」または「kexecコマンドが記録されていません」と表示される場合、キャプチャカーネルに有効なロードがありません。
分析のためのもう 1 つの基本的な詳細: クラッシュにはシンボルを含むカーネル バイナリが必要です。 分析に適したファイルは vmlinux （非圧縮、 デバッグシンボル）、一方 vmlinuz これは起動時に読み込まれる圧縮バージョンです。正しいバイナリがない場合、crashは起動したカーネルが見つからないというエラーを出し、正しい名前リストを要求する可能性があります。最適なスキャンを実現するために、カーネル用の-dbg/-debuginfoパッケージをインストールしてください。
よくある問題、その解決方法、クラッシュ分析
再起動後に実行する場合 systemctl status kdump.service 失敗していることに気づいたら、まずはメッセージを注意深く読んでください。よくある実例は以下の通りです。 「セキュアブートが有効です。kexecファイルベースのシステムコールを使用しています」 「kdumpカーネルのロードに失敗しました」というメッセージが表示されます。セキュアブートが有効になっている場合、システムは「ファイルベース」の kexecキャプチャ カーネルまたはその initrd がファームウェアによって期待どおりに署名されていない場合、失敗する可能性があります。
このシナリオで確認すべきこと： キャプチャカーネルとそのinitrdはセキュアブートに適しています、パッケージ kexec-tools 最新であり、kdump initrd に未署名の重要なモジュールはありません。セキュリティフレームワークで許可されている場合は、セキュアブートを一時的に無効にして問題を切り分けることで、問題の根本原因が署名なのかメモリ割り当てなのかを判別しやすくなります。
Ubuntu/Debian では、kdump の読み込み時に発生する別のエラーとして、「0x943c000 バイトの空きメモリ領域が見つかりませんでした… locate_hole が失敗しました」というものがあります。これは、キャプチャ カーネルに必要なサイズの連続したメモリ領域が見つからなかったことを示しています。典型的な原因としては、メモリの断片化、割り当て不足、または現在のレイアウトとの競合などが挙げられます。
「locate_hole failed」および類似のエラーに対する実際的な対処法：
- 準備金を減らすか調整する：
crashkernel=256M512Mの場合、またはその逆。一部のコンピュータでは、中間値の方がより適切に機能します。auto. - 起動時にメモリを断片化するパラメータを少なくして起動し、 GRUBを再生成するようにしてください 変更後（
grub2-mkconfigoupdate-grub). - リンクを確認してください
/var/lib/kdump/vmlinuzeinitrd.img正しいキャプチャカーネルを指し示し、 kdump initrdがあります. - 要求の厳しいデバイスや IOMMU を備えたマシンでは、セグメント (ゾーン予約スキームなど) を含む crashkernel 値が役立ちます。 ディストリビューションが定義済みのプロファイルを文書化している場合発明する前に試してみてください。
サービスが「kdump: Starting kdump: 」および「Main process exited, status=1/FAILURE」と報告した場合は、基本に戻ります。 キャプチャカーネルは実際にロードされましたか? 走る kdumpctl start o kdump-config load システムに応じて、出力全体を確認してください。initrdの作成、シンボリックリンク、そしてメモリ割り当ての失敗に関するメッセージはすべて、要求されたサイズの連続した領域が不足しているという共通の根本原因を示しています。
また、グラフィカル環境（KDE、GNOMEなど）はここでは関係ありません。kdumpはカーネルおよびブートレベルで動作します。「KDEで動作させるにはどうすればいいですか？」と聞かれた場合、問題はデスクトップ環境ではなく、ファームウェア（セキュアブート）、ブートマネージャ、メモリ割り当て、およびキャプチャカーネル/initrdの適切なパッケージングにある、というのが答えです。
ルートの特殊性に戻ります。 /var/crash/var/crash、 チェックアウト /etc/kdump.confダンプターゲットがマウントされている場合 /var/crash およびオプション path それも /var/crash, 結果は重複したルートです。 確立します path / そして問題は解決しました。
ダンプを生成したら（例： vmcore とともに vmcore-dmesg.txt y kexec-dmesg.log）、クラッシュを使用するタイミングです。 クラッシュはvmcoreとバイナリをロードします vmlinux 記号付き 豊富な分析環境が開き、プロセス、コールスタック、モジュール、メモリ、ロックなどを一覧表示できます。これは、gdbを試してみるのに比べて理想的なアプローチです。 /proc/kcoreこれは多くの場合制限があり、カーネルのコンパイル方法に依存します。
実稼働していないシステム（またはファイルをコピーした後）で作業するには、vmcoreと vmlinux 十分です。 正しいvmlinuxがないと分析はうまくいかない内部構造を解釈するためのシンボルが不足しているためです。ディストリビューションが-debuginfoまたは-dbgカーネルパッケージを提供している場合は、それらをインストールして使用してください。 vmlinux vmcore バージョンに対応します。
セキュリティへの影響を理解することが重要です。vmcoreには、クラッシュ時にメモリ内にあった「すべて」が含まれています。 機密データ、鍵、会話の断片 プロセスとカーネル内で実行されていたものすべて。したがって、 /var/crash ダンプは他の秘密情報と同様に慎重に扱う必要があります。ダンプを見るべきではないユーザーがアクセスできる状態にしないでください。
完全なカーネルダンプが必要ない場合、特定のプロセスをデバッグすることが目的であれば、次のようなツールでプロセスダンプを生成する方が侵襲性が低い戦略です。 gcore. プロセスダンプはより小さく、管理しやすくなりました、また、特定のアプリがクラッシュするなど、ユースケースを分離することができます。ただし、機密性の高いプロセスデータが漏洩するリスクは残るため、同様の予防措置が適用されます。 ストレージ そして許可します。
適切な運用手順を徹底するために、ミッションクリティカルな環境では、カーネルとkexec-toolsを更新した後、必ずkdumpを実行してください。実際のインシデント発生時よりも、メンテナンス期間中にキャプチャカーネルが「起動しない」ことに気づく方がはるかに良いでしょう。また、開発チームまたはサポートチーム向けに、vmcoreのパス、保持期間、および安全な抽出/転送手順を文書化してください。
信号とアクションの実践的な概要：
- ステータスに「kdump の準備ができていません」と表示されるか、kexec コマンドが登録されません。 キャプチャカーネルのロードが見つかりません; crashkernel、kdump initrd をチェックし、ディストリビューションのツールを使用してリロードします。
- セキュアブートがアクティブで「kexec ファイルベースのシステムコール」: 署名と互換性を検証する カーネル/initrd キャプチャから、またはセキュア ブートなしでテストして障害を特定します。
- 「locate_hole 失敗」: 設定 のサイズ
crashkernel=断片化を軽減 起動時にリンクを確認し、GRUB を再生成します。 - 捨てられた
/var/crash/var/crash: 修正path /enkdump.confFSがマウントされている場合/var/crash.
すべてが整ったら、理想的な流れは次のようになります。パニックが発生し、kexecがキャプチャカーネルを起動し、makedumpfileがメモリを収集してvmcoreを合意されたパスに保存し、あなたまたはあなたのチームがクラッシュでケースを開き、 vmlinux 心配。 それがインシデントと学習の間の最短経路です。、そして可視性のないエラーの繰り返しからあなたを救うもの。
各プラットフォームには微妙な違いがありますが、基本は同じです。十分な連続したメモリを予約し、アクティブなときにセキュアブートの要件を尊重し、ダンプパスをマウントポイントに適切に配置して、常に vmlinux 衝突分析用の手描きのシンボル付き。 これらの要素が整うと、kdump は謎ではなくなり、ブラック ボックスになります。 カーネルが警告なしに着陸することを決定した場合。
バイトの世界とテクノロジー全般についての情熱的なライター。私は執筆を通じて自分の知識を共有するのが大好きです。このブログでは、ガジェット、ソフトウェア、ハードウェア、技術トレンドなどについて最も興味深いことをすべて紹介します。私の目標は、シンプルで楽しい方法でデジタル世界をナビゲートできるよう支援することです。