第7章 カーネルクラッシュダンプガイド

7.1. kdump について

7.1.1. kdump と kexec について

kdump とは、システムのメモリー内容を保存して後で分析できるようにカーネルのクラッシュをダンプする仕組みを指します。kdump は kexec に依存し、この kexec を使用して、別のカーネルのコンテキストから Linux カーネルを起動し、BIOS を迂回して通常は失われてしまう 1 番目のカーネルメモリーの内容を保持することができます。

システムクラッシュが発生すると kdump は kexec を使用して 2 番目のカーネルで起動します (キャプチャーカーネル)。この 2 番目のカーネルはシステムメモリーの予約部分に収納されていて 1 番目のカーネルからはアクセスできません。2 番目のカーネルは起動するとクラッシュしたカーネルメモリーの内容 (クラッシュダンプ) をキャプチャーして保存します。

重要

カーネルクラッシュダンプは、障害時に唯一利用可能な情報である可能性があるので、ビジネスに不可欠な環境ではこのデータの重要性を過小評価してはいけません。Red Hat は、システム管理者に対して、通常のカーネル更新サイクルで kexec-tools を定期的に更新し、テストすることを推奨しています。これは、新しいカーネル機能が実装されている場合に特に重要です。

注記

HP Watchdog タイマー (hpwdt) ドライバーは、RHEV ハイパーバイザーとして実行中されている HP システムで事前に読み込まれるため、これらのシステムは NMI ウォッチドッグを使用できます。kexec-tools-2.0.15-33.el7.x86_64 から開始する更新された kexec-tools パッケージは hpwdt ドライバーを事前に読み込みます。

ドライバー bnx2x および bmx2fc が kdump カーネルのブラックリストに入れられ、2 つ目のカーネルがパニックを生じさせ、ダンプはキャプチャーされません。

7.1.2. メモリー要件

kdump でカーネルクラッシュダンプをキャプチャーしてさらに分析ができるように保存するにはシステムメモリーの一部をキャプチャーカーネル用に永続的に予約する必要があります。予約するとその部分はメインカーネルでは使用できなくなります。

メモリー要件は、特定のシステムパラメーターによって異なります。主な要因は、システムのハードウェアアーキテクチャーです。以下のコマンドをシェルプロンプトで入力してマシンの正確なアーキテクチャー名を特定し (x86_64 など)、これを標準出力に表示します。

uname -m

予約すべきメモリーサイズを左右する別の要因として搭載しているシステムメモリーの総量が影響します。たとえば、x86_64 アーキテクチャーでは予約メモリーは 4 KB のメモリーごとに、160 MB + 2 ビットになります。搭載されている物理メモリーの合計が 1 TB のシステムの場合には 224 MB (160 MB + 64 MB) ということになります。システムアーキテクチャーごとの kdump メモリー要件と物理メモリー量についての詳細は 「kdump メモリー要件」を参照してください。

多くのシステムでは必要なメモリー量は kdump によって自動的に算出、予約が行われます。この動作はデフォルトで有効になっていますが、利用可能な合計メモリーサイズが一定以上搭載されているシステムに限られます。この自動割り当て動作に必要なメモリーサイズはシステムのアーキテクチャーによって異なります。システムアーキテクチャーに基づいた自動メモリー割り当てに必要な最小メモリーサイズの一覧は、「メモリー自動予約の最小しきい値」を参照してください。

システムメモリーが自動割り当ての動作に必要な最小メモリーに満たない場合、または独自の予約メモリーサイズを必要とするような場合には予約メモリーを手動で設定することができます。コマンドラインでこの作業を行う場合は 「メモリー使用量の設定」を参照してください。グラフィカルユーザーインターフェースでこの作業を行う場合は「メモリー使用量の設定」を参照してください。

重要

kdump サービスを設定したら、自動メモリー割り当てであっても設定のテストを行うことを強く推奨します。設定のテスト方法については「kdump 設定のテスト」を参照してください。

7.2. kdump のインストールと設定

7.2.1. kdump のインストール

多くの場合、Red Hat Enterprise Linux 7 の新規インストールで、kdump サービスはデフォルトでインストールされ、アクティブにされます。グラフィカルインターフェースまたはテキストインターフェースを使って対話形式でインストールする場合には、Anaconda インストーラーに kdump の設定画面があります。インストーラー画面には、Kdump というタイトルが付けられ、メイン画面の Installation Summary からアクセスできます。kdump を有効にするかどうかとどの程度メモリーを予約するかについてのみ選択できます。kdump のメモリー要件の詳細は、「kdump メモリー要件」を参照してください。インストーラーの kdump 設定画面は 『Red Hat Enterprise Linux 7 インストールガイド』 で説明しています。

注記

Red Hat Enterprise Linux の以前のリリースでは Firstboot ユーティリティーで kdump の設定ができました。このユーティリティーはインストールの終了後、システムをはじめて再起動すると自動的に実行されていました。Red Hat Enterprise Linux 7.1 からは kdump の設定がインストーラー内に移動しています。

カスタムのキックスタートを使ったインストールなど一部のインストール方法では、デフォルトで kdump をインストールしない場合または有効にしない場合があります。お使いのシステムでも同様で、kdump を追加でインストールする必要がある場合には、root で以下のコマンドをシェルプロンプトから実行します。

# yum install kexec-tools

お使いのシステムアーキテクチャー向けの kexec-tools パッケージが含まれるカスタムのリポジトリーか、アクティブなサブスクリプションがシステムにある場合に、上記のコマンドで kdump およびその他に必要なパッケージすべてが確実にインストールされます。

注記

システムに kdump がインストールされているかわからない場合は、rpm を使用して確認できます。

$ rpm -q kexec-tools

この他、グラフィカルな設定ツールもあります。ただし上記のコマンドを使った場合に、デフォルトではグラフィカルな設定ツールはインストールされません。「グラフィカルユーザーインターフェースでの kdump の設定」 で説明されているようにこのユーティリティーをインストールするには、 root で以下のコマンドを使用します。

# yum install system-config-kdump

Yum を使用した Red Hat Enterprise Linux 7 の新規パッケージのインストール方法は『Red Hat Enterprise Linux 7 システム管理者のガイド』を参照してください。

重要

Red Hat Enterprise Linux 7.4 以降では、Intel IOMMU ドライバーが kdump でサポートされます。7.3 以前のバージョンのカーネルを実行する場合は、 Intel IOMMU サポートを有効にすることが推奨されます。

7.2.2. コマンドラインで kdump の設定

7.2.2.1. メモリー使用量の設定

kdump カーネル用に予約されるメモリーは必ずシステムの起動時にその予約が行われます。 つまり、メモリーのサイズはシステムのブートローダー設定で指定されています。

kdump カーネル用に予約するメモリーを指定するには、 crashkernel= オプションを必要な値に設定します。たとえば、128 MB のメモリーを予約するには、以下を使用します。

crashkernel=128M

crashkernel= オプションを GRUB2 ブートローダーを使用して AMD64 および Intel 64 システムおよび IBM Power Systems サーバーで変更したり、zipl を使用して IBM Z で変更する方法については、「「カーネルコマンドラインパラメーターの設定」」を参照してください。

crashkernel= オプションは、複数の方法で定義できます。「kdump メモリー要件」 で説明されているガイドラインに従い、auto 値を指定すると、システムの合計メモリーに基づいた、予約されたメモリーの自動設定が可能になります。メモリーサイズが大きいシステムでは、オペレーティングシステムに設定された上限について、crashkernel=auto オプションが指定されたアーキテクチャーに従って計算されます。

この動作を変更するには、auto 値を特定のメモリー量に置き換えます。

crashkernel= オプションは、とくにメモリー量の少ないシステムの場合に役立ちます。たとえば、128 MB のメモリーを予約するには、以下を使用します。

crashkernel=128M

搭載しているメモリーの合計サイズに応じて予約メモリーサイズが可変するように設定することもできます。変数のメモリー予約の構文は crashkernel=<range1>:<size1>,<range2>:<size2> です。以下に例を示します。

crashkernel=512M-2G:64M,2G-:128M

上記の例では、システムメモリーの合計が 512 MB 以上 2 GB 未満の場合、64 MB のメモリーを予約します。メモリー合計サイズが 2 GB を超える場合は、128 MB が kdump 用に予約されます。

システムによっては、特定の固定オフセットを指定して、メモリーの予約を行う必要があります。オフセットが設定されると、予約メモリーはそこから開始されます。予約メモリーをオフセットするには、以下の構文を使用します。

crashkernel=128M@16M

上記の例の場合、kdump は 128 MB のメモリー予約を 16 MB (物理アドレス 0x01000000) から開始することになります。オフセットパラメーターを 0 に設定する、または完全に省略すると kdump により自動的にオフセットが設定されます。上記のように、変数メモリー予約を設定する場合にもこの構文を使用します。この場合、オフセットは常に最後に指定されます (例: crashkernel=512M-2G:64M,2G-:128M@16M)。

7.2.2.2. kdump タイプの設定

カーネルクラッシュがキャプチャーされると、コアダンプはローカルファイルシステムのファイルとして保存したり、デバイスに直接書き込みしたり、NFS (Network File System) または SSH (Secure Shell) プロトコルを使用してネットワーク上で送信したりすることができます。現時点で設定できるのは、これらのオプションの 1 つのみです。デフォルトのオプションでは、vmcore ファイルをローカルファイルシステムの /var/crash ディレクトリーに保存します。

vmcore ファイルをローカルファイルシステムの /var/crash/ ディレクトリーに保存するには、以下を実行します。

  • /etc/kdump.conf ファイルを編集し、パスを指定します。

    path /var/crash

    オプション path /var/crash は、 kdumpvmcore ファイルを保存するファイルシステムパスを表します。/etc/kdump.conf ファイルでダンプターゲットを指定する場合、path は指定されたダンプターゲットの相対パスになります。

    /etc/kdump.conf ファイルでダンプターゲットを指定しない場合、path はルートディレクトリーの絶対パスを表します。現在のシステムにマウントされている内容に応じて、ダンプターゲットと調整されるダンプパスが自動的に適用されます。

警告

kdump は、ダンプターゲットが /var/crash にマウントされ、オプション path/etc/kdump.conf ファイルの /var/crash として設定される場合、/var/crash/var/crash ディレクトリーに vmcore ファイルを保存します。たとえば、以下の例では、ext4 ファイルシステムはすでに /var/crash にマウントされ、path/var/crash として設定されます。

grep -v ^# etc/kdump.conf | grep -v ^$
ext4 /dev/mapper/vg00-varcrashvol
path /var/crash
core_collector makedumpfile -c --message-level 1 -d 31

これにより、/var/crash/var/crash パスが生成されます。この問題を解決するには、path /var/crash ではなく、path / オプションを使用します。

ダンプの場所を変更するには、root としてテキストエディターで /etc/kdump.conf 設定ファイルを開き、以下のようにオプションを編集します。

コアダンプの保存先のローカルディレクトリーを変更する場合は、#path /var/crash 行の先頭にあるハッシュ記号 ("#") を取り除き、値を変更先のディレクトリーパスに置き換えます。

path /usr/local/cores
重要

Red Hat Enterprise Linux 7 では、path ディレクティブを使用して kdump のダンプ出力先として定義されているディレクトリーが kdump systemd サービスの起動時に存在していなければなりません。存在しない場合、サービスは失敗します。この動作は、サービスの起動時にそのディレクトリーが存在しない場合に自動的に作成されていた Red hat Enterprise Linux の以前のリリースのものとは異なります。

オプションで、ファイルを別のパーティションに書き込む場合は、#ext4 で始まる行のいずれかで同じ手順を実行します。ここでは、デバイス名 (#ext4 /dev/vg/lv_kdump 行)、ファイルシステムのラベル (#ext4 LABEL=/boot 行)、または UUID ( #ext4 UUID=03138356-5e61-4ab3-b58e-27507ac41937 行) のいずれかを使用できます。ファイルシステムタイプと、デバイス名、ラベル、UUID を希望の値に変更します。以下に例を示します。

ext4 UUID=03138356-5e61-4ab3-b58e-27507ac41937
重要

LABEL= または UUID= を使用してストレージデバイスを指定することが推奨されます。/dev/sda3 などのディスクデバイス名については、再起動後の一貫性は保証されません。永続的なディスクデバイスの命名については『Red Hat Enterprise Linux 7 ストレージ管理ガイド』を参照してください。

重要

s390x ハードウェア上の DASD にダンプする場合には、続行する前に /etc/dasd.conf でダンプデバイスが正しく指定されている必要があります。

ダンプをデバイスに直接書き込む場合は、#raw /dev/vg/lv_kdump の行頭にあるハッシュ記号 (#) を取り除き、値をダンプ出力先のデバイス名に置き換えます。以下に例を示します。

raw /dev/sdb1

NFS プロトコルを使用してリモートのマシンにダンプを保存するには、#nfs my.server.com:/export/tmp の行頭にあるハッシュ記号 ("#") を取り除き、値を有効なホスト名およびディレクトリーパスに置き換えます。以下に例を示します。

nfs penguin.example.com:/export/cores

SSH プロトコルを使用してダンプをリモートマシンに保存するには、#ssh user@my.server.com の行頭にあるハッシュ記号 ("#") を取り除き、値を有効なユーザー名およびホスト名に置き換えます。設定に SSH キーも含める場合は、#sshkey /root/.ssh/kdump_id_rsa の行頭にあるハッシュ記号 ("#") を取り除き、値をダンプの出力先となるサーバー上で有効なキーの場所に変更します。以下に例を示します。

ssh john@penguin.example.com
sshkey /root/.ssh/mykey

SSH サーバーの設定方法およびキーベースの認証設定については『Red Hat Enterprise Linux 7 システム管理者のガイド』を参照してください。

対応しているダンプ出力先と非対応のダンプ出力先のタイプ別一覧は表7.4「対応している kdump のダンプ出力先」を参照してください。

7.2.2.3. コアコレクターの設定

vmcore ダンプファイルのサイズを小さくするために、kdump では外部アプリケーション (コアコレクター) を指定して、データの圧縮や必要に応じた関連性のないすべての情報の除外を実行できます。現在、完全にサポートされている唯一のコアコレクターは makedumpfile です。

コアコレクターを有効にするには root としてテキストエディターで /etc/kdump.conf 設定ファイルを開き、#core_collector makedumpfile -l --message-level 1 -d 31 行の先頭にあるハッシュ記号 (#) を取り除き 、以下のようにコマンドラインオプションを編集します。

ダンプファイルの圧縮を有効にするには、-l パラメーターを追加します。以下に例を示します。

core_collector makedumpfile -l

ダンプから特定のページを取り除くには、-d value パラメーターを追加します。ここで、 は、 表7.5「サポートしているフィルターレベル」で説明されているように、省略するページの値の合計になります。ゼロと未使用ページを除外する場合は次のようになります。

core_collector makedumpfile -d 17 -c

利用可能なオプションの詳細一覧は、 makedumpfile(8) man ページを参照してください。

7.2.2.4. デフォルト動作の設定

デフォルトでは、kdump が、「kdump タイプの設定」 で指定したダンプ出力先でコアダンプの作成に失敗すると、 kdump は vmcore を保存せずにシステムを再起動します。この動作を変更するには、root/etc/kdump.conf 設定ファイルをテキストエディターで開き、#default shell の行頭にあるハッシュ記号 ("#") を取り除き、表7.6「サポートしているデフォルトの動作」で説明されているように値を必要な動作に変更します。

以下に例を示します。

default reboot

7.2.2.5. サービスの有効化

起動時に kdump デーモンを開始するには、シェルプロンプトで root として以下を入力します。

systemctl enable kdump.service

これにより、multi-user.target のサービスが有効になります。同様に、systemctl disable kdump を入力すると、 kdump が無効になります。現行セッションでサービスを開始するには、以下のコマンドを root で使用します。

systemctl start kdump.service
重要

Red Hat Enterprise Linux 7 では、kdump の出力先として定義さてるディレクトリーが、kdump systemd サービスの起動時に存在していなければなりません。存在しない場合、サービスは失敗します。この動作は、サービスの起動時にそのディレクトリーが存在しない場合に自動的に作成されていた Red hat Enterprise Linux の以前のリリースのものとは異なります。

systemd およびサービスの設定全般については『Red Hat Enterprise Linux 7 システム管理者のガイド』を参照してください。

7.2.3. グラフィカルユーザーインターフェースでの kdump の設定

Kernel Dump Configuration ユーティリティーを起動するには、パネルから ActivitiesOtherKernel crash dumps を選択するか、またはシェルプロンプトで system-config-kdump を入力します。図7.1「基本設定」に示すウィンドウが表示されます。

このユーティリティーを使用すると、kdump の設定できるほか、起動時にサービスの開始を有効または無効にすることもできます。設定が完了したら 適用 をクリックして変更を保存します。認証が済んでいる場合を除きスーパーユーザーのパスワード入力が求められます。また、設定の変更を適用するにはシステムの再起動が必要な旨を示すメッセージが表示されます。

重要

SELinux が Enforcing モードで実行されている IBM Z または PowerPC システムでは、カーネルダンプ設定ユーティリティーを起動する前に kdumpgui_run_bootloader のブール値を有効にする必要があります。このブール値により、system-config-kdump が bootloader_t SELinux ドメインのブートローダーで実行できるようになります。このブール値を永続的に有効化するには、root として以下のコマンドを実行します。

# setsebool -P kdumpgui_run_bootloader 1
重要

s390x ハードウェア上の DASD にダンプする場合には、続行する前に /etc/dasd.conf でダンプデバイスが正しく指定されている必要があります。

7.2.3.1. メモリー使用量の設定

Basic Settings タブを使用すると、kdump カーネル用に予約されるメモリー量を設定できます。これを実行するには、Manual settings ラジオボタンを選択し、New kdump Memory フィールドの横にある上下矢印ボタンをクリックして予約するメモリーサイズを増減させます。Usable Memory フィールドは随時変更され、システムで使用できるメモリーの残量が表示されることに留意してください。kdump のメモリー要件については 「メモリー要件」 を参照してください。

図7.1 基本設定

基本設定

7.2.3.2. kdump タイプの設定

Target Settings タブでは vmcore ダンプのターゲットの場所を指定できます。ダンプはローカルのファイルシステムにファイルとして保存するか、デバイスに直接書き込むか、または NFS (Network File System) や SSH (Secure Shell) プロトコルを使用してネットワーク経由で送信することができます。

図7.2 出力先

出力先

ローカルファイルシステムにダンプを保存するには Local filesystem ラジオボタンを選択します。オプションで、Partition ドロップダウンリストから別のパーティションを選択し、Path フィールドで出力先ディレクトリーを選択して設定をカスタマイズすることもできます。

重要

Red Hat Enterprise Linux 7 では、kdump の出力先として定義さてるディレクトリーが、kdump systemd サービスの起動時に存在していなければなりません。存在しない場合、サービスは失敗します。この動作は、サービスの起動時にそのディレクトリーが存在しない場合に自動的に作成されていた Red hat Enterprise Linux の以前のリリースのものとは異なります。

デバイスに直接ダンプを書き込む場合は、Raw device ラジオボタンを選択し、必要な出力先デバイスをその横にあるドロップダウンリストから選択します。

ネットワーク接続経由でリモートマシンにダンプを送信するには、Network ラジオボタンを選択します。NFS プロトコルを使用するには、NFS ラジオボタンを選択して Server name および Path to directory フィールドに入力します。SSH プロトコルを使用するには、SSH ラジオボタンを選択して Server namePath to directory、および User name フィールドにリモートサーバーアドレス、ターゲットディレクトリー、有効なユーザー名をそれぞれ入力します。

SSH サーバーの設定方法およびキーベースの認証設定については『Red Hat Enterprise Linux 7 システム管理者のガイド』を参照してください。現在サポートしている出力先の一覧については 表7.4「対応している kdump のダンプ出力先」 を参照してください。

7.2.3.3. コアコレクターの設定

Filtering Settings タブを使用すると、vmcore ダンプのフィルタリングレベルを選択できます。

図7.3 フィルタリング

フィルタリング

ダンプから zero pagecache pagecache privateuser data、または free page を実行するには、該当するラベルの横にあるチェックボックスを選択します。

7.2.3.4. デフォルト動作の設定

kdump がコアダンプを作成できない場合に実行する動作を選択するには、Action if dumping fails ドロップダウンリストから適切なオプションを選択します。利用可能なオプションは以下の通りです。

  • rootfs および reboot へのダンプ を使用すると、コアをローカルに保存して、システムを再起動します。
  • Reboot システムを再起動するデフォルトの動作
  • シェルの開始 アクティブなシェルプロンプトでユーザーを表示します。
  • halt システムを停止します。
  • Poweroff システムの電源を切ります。

図7.4 フィルタリング

エキスパート設定

makedumpfile コアコレクターに渡されるオプションをカスタマイズするには、 Core collector テキストフィールドを編集します。詳細は、「コアコレクターの設定」 を参照してください。

7.2.3.5. サービスの有効化

起動時に kdump サービスを開始するには、ツールバーで Enable ボタンをクリックしてから Apply ボタンをクリックします。これにより、サービスが有効にされ、multi-user.target のサービスがアクティブになります。無効化 ボタンをクリックして適用 ボタンをクリックするとサービスが直ちに無効になります。

重要

Red Hat Enterprise Linux 7 では、kdump の出力先として定義さてるディレクトリーが、kdump systemd サービスの起動時に存在していなければなりません。存在しない場合、サービスは失敗します。この動作は、サービスの起動時にそのディレクトリーが存在しない場合に自動的に作成されていた Red hat Enterprise Linux の以前のリリースのものとは異なります。

systemd の出力先およびサービスの設定全般については『Red Hat Enterprise Linux 7 システム管理者のガイド』を参照してください。

7.3. kdump のカーネルドライバーのブラックリスト化

カーネルドライバーのブラックリスト化により、それらの読み込みや使用が禁止されます。/etc/sysconfig/kdump ファイルでドライバーを追加すると、kdump initramfs がブラックリストに指定されたモジュールを読み込むことができなくなります。

カーネルドライバーをブラックリストに指定すると、 oom Killer その他のカーネルのクラッシュに関する障害が発生しなくなります。カーネルドライバーをブラックリストに指定するには、/etc/sysconfig/kdump ファイルで KDUMP_COMMANDLINE_APPEND= 変数を更新し、以下のブラックリストオプションのいずれかを指定できます。

  • rd.driver.blacklist=<modules>
  • modprobe.blacklist=<modules>

手順

  1. ブラックリストに指定するカーネルモジュールを選択します。

    $ lsmod
    Module                  Size  Used by
    fuse                  126976  3
    xt_CHECKSUM            16384  1
    ipt_MASQUERADE         16384  1
    uinput                 20480  1
    xt_conntrack           16384  1

    lsmod コマンドは、現在実行中のカーネルに読み込まれるモジュールの一覧を表示します。

  2. /etc/sysconfig/kdump ファイルの KDUMP_COMMANDLINE_APPEND= 行を以下のように更新します。

    KDUMP_COMMANDLINE_APPEND="rd.driver.blacklist=hv_vmbus,hv_storvsc,hv_utils,hv_netvsc,hid-hyperv"
  3. /etc/sysconfig/kdump ファイルの KDUMP_COMMANDLINE_APPEND= 行を以下のように更新することもできます。

    KDUMP_COMMANDLINE_APPEND="modprobe.blacklist=emcp modprobe.blacklist=bnx2fc modprobe.blacklist=libfcoe modprobe.blacklist=fcoe"
  4. kdump サービスを再起動します。

    $ systemctl restart kdump

7.4. kdump 設定のテスト

警告

以下のコマンドでは、カーネルがクラッシュします。次の手順を行う場合は十分に注意してください。 実稼働のシステムでは絶対に実行しないでください。

設定をテストするには、kdump を有効にしてシステムを再起動し、サービスが実行中であることを確認します。

~]# systemctl is-active kdump
active

次に、シェルプロンプトで以下のコマンドを入力します。

echo 1 > /proc/sys/kernel/sysrq
echo c > /proc/sysrq-trigger

これにより、Linux カーネルが強制的にクラッシュし、address-YYYY-MM-DD-HH:MM:SS/vmcore ファイルが設定で選択した場所にコピーされます (デフォルトは /var/crash/)。

注記

このアクションは、設定の妥当性を確認するのに加え、典型的なテストロードで実行された場合にクラッシュダンプが完了するまでの所要時間を記録するために使用できます。

7.4.1. 関連情報

7.4.1.1. インストールされているドキュメント

  • kdump.conf(5): 利用できるオプションの詳細なドキュメントを含む /etc/kdump.conf 設定ファイルの man ページです。
  • zipl.conf(5): /etc/zipl.conf 設定ファイルの man ページです。
  • zipl(8): IBM Z 用の zipl ブートローダーユーティリティーの man ページです。
  • makedumpfile(8): makedumpfile コアコレクターの man ページです。
  • kexec(8) — kexec の man ページです。
  • crash(8) — crash ユーティリティの man ページです。
  • /usr/share/doc/kexec-tools-version/kexec-kdump-howto.txt - kdump および kexec のインストールと使用についての概要

7.4.1.2. オンラインドキュメント

https://access.redhat.com/site/solutions/6038
kexec および kdump 設定についての Red Hat ナレッジベースアーティクル
https://access.redhat.com/site/solutions/223773
サポートしている kdump ターゲットについての Red Hat ナレッジベースアーティクル。
https://github.com/crash-utility/crash
crash ユーティリティー Git リポジトリー。
https://www.gnu.org/software/grub/
GRUB2 ブートローダーのホームページとドキュメントです。

7.5. ファームウェア支援ダンプの仕組み

7.5.1. ファームウェア支援ダンプについて

kexec および kdump のメカニズムは、AMD64 および Intel 64 システムでコアダンプをキャプチャーする信頼できる証明済みの方法です。ただし、特に小規模システムおよびメインフレームシステムのような長い歴史を持つハードウェアでは、オンボードファームウェアを活用してメモリの領域を分離し、クラッシュ分析に重要なデータの偶発的な上書きを防ぐことができます。

本章では、利用可能なファームウェア支援ダンプの手法について紹介し、ファームウェア支援ダンプを Red Hat Enterprise Linux でどのように活用するかについて説明します。

7.5.2. IBM PowerPC ハードウェアにおける fadump の使用

ファームウェア支援ダンプ (fadump) は、IBM PowerPC LPARS で利用可能な kexec-kdump に代わる信頼性の高い仕組みです。ファームウェア支援ダンプでは、PCI および I/O デバイスが再初期化され、完全にリセットされたシステムから、vmcore がキャプチャーされます。この仕組みでは、クラッシュの発生時にファームウェアを使ってメモリーが保持されますが、 kdump ユーザー空間スクリプトが再利用して vmcore を保存します。

そのために、fadump では、クラッシュ発生時にシステムファームウェアを使って保持する必要のあるメモリー領域を登録します。これらの領域には、ブートメモリー、システムレジスター、およびハードウェアのページテーブルエントリー (PTE) を除く、すべてのシステムメモリーコンテンツが含まれます。

fadump の仕組みについての詳細 (PowerPC 固有のハードウェアのリセット方法を含む)、/usr/share/doc/kexec-tools-X.y.z/fadump-howto.txt を確認してください。ここで、「X.y.z」 は、お使いのシステムにインストールされている kexec-tools のバージョン番号に対応します。

注記

boot memory として知られる、保持されないメモリー領域は、クラッシュの発生後にカーネルを正常に起動するのに必要な RAM の容量になります。デフォルトのブートメモリーサイズは、256 MB または全システム RAM の 5% のいずれか大きい方です。

kexec で開始されるイベントとは異なり、fadump プロセスでは実稼働用のカーネルを使用してクラッシュダンプを復元します。クラッシュ後の起動時に、PowerPC ハードウェアはデバイスノード /proc/device-tree/rtas/ibm,kernel-dumpprocfs で利用できるようにし、fadump 対応の kdump スクリプトは vmcore を保存するためにこれをチェックします。この処理が完了すると、システムは正しく再起動されます。

fadump の有効化

  1. 「kdump のインストールと設定」 で説明されているように kdump をインストールし、設定します。
  2. fadump=on/etc/default/grubGRUB_CMDLINE_LINUX 行に追加します。

    GRUB_CMDLINE_LINUX="rd.lvm.lv=rhel/swap crashkernel=auto rd.lvm.lv=rhel/root rhgb quiet fadump=on"
  3. (オプション)デフォルトを許可する代わりに予約されたブートメモリーを指定する場合、/etc/default/grubcrashkernel=xxMGRUB_CMDLINE_LINUX に設定します。ここで、xx は必要なメモリーサイズ (メガバイト単位) になります。

    GRUB_CMDLINE_LINUX="rd.lvm.lv=rhel/swap crashkernel=xxM rd.lvm.lv=rhel/root rhgb quiet fadump=on"
重要

すべてのブート設定オプションと同様に、必要になる前に設定をテストすることを強く推奨します。クラッシュカーネルより、起動時に Out of Memory (OOM) エラーが発生する場合は、クラッシュカーネルが正常に起動できるまで crashkernel= で指定する値を増やします。この場合は、トライアンドエラーが必要になることがあります。

7.5.3. IBM Z におけるファームウェア支援ダンプの手法

IBM Z には 2 つのファームウェア支援ダンプメカニズムがあります。それらは、Stand-alone Dump および VMDUMP です。

これらのシステムでは kdump インフラストラクチャーがサポートされ使用されています。Red Hat Enterprise Linux での設定は、「kdump のインストールと設定」に説明があります。ただし、IBM Z ハードウェアが提供するこれらのファームウェア支援の手法を使用すると、いくつかのメリットが得られます。

スタンドアロンダンプ (SADMP) メカニズムはシステムコンソールから開始および制御され、IPL 起動可能デバイス上に保管される必要があります。

VMDUMP は SADMP と類似しています。このツールもシステムコンソールから開始されますが、得られるダンプをハードウェアからコピーし、解析のためにそれをシステムに格納する仕組みがあります。

(他のハードウェアベースのダンプメカニズムと同様に) これらの手法のメリットの 1 つは、(kdump サービスが開始される前の) 起動初期段階におけるマシンの状態をキャプチャーできるという点です。

VMDUMP には、ハードウェアからコピーしたダンプファイルを Red Hat Enterprise Linux システムに格納する仕組みがありますが、IBM Z ハードウェアコンソールから、SADMP および VMDUMP の両方の設定および制御が管理されます。

IBM は、stand-alone dump programの記事で SADMP について、VMDUMP の記事で VMDUMP について詳細に説明しています。

また、IBM は、Using the Dump Tools on Red Hat Enterprise Linux 記事で Red Hat Linux Enterprise Linux 7 でダンプツールを使用するための一連のドキュメントを用意しています。

7.5.4. Fujitsu PRIMEQUEST システムにおける sadump の使用

Fujitsu の sadump メカニズムは、kdump が正常に完了できない場合にフォールバックダンプキャプチャーが実行されるように設計されています。

sadump プロセスは、システムの ManageMent Board (MMB) インターフェースから手動で呼び出します。

このシステムでは、通常通り kdump を X86_64 サーバーに対して設定し、さらに以下の追加ステップを実施して sadump を有効にする必要があります。

/etc/sysctl.conf で以下の行を追加または編集し、kdumpsadump について予想通りに起動するようにします。

kernel.panic=0
kernel.unknown_nmi_panic=1

上記の手順に加えて、/etc/kdump.conf にいくつかのオプションを追加して、sadump に対して kdump が正常に動作するようにする必要もあります。

特に、kdump の後にシステムが再起動しないようにする必要があります。kdump がコアの保存に失敗した後にシステムが再起動すると、sadump を呼び出す機会が失われます。

そのために、/etc/kdump.confdefault アクションを halt または shell のいずれかに設定します。

default shell
重要

sadump 用にハードウェアを設定する方法は、『FUJITSU Server PRIMEQUEST 2000 Series Installation Manual』を参照してください。

7.6. コアダンプの分析

システムクラッシュの原因を確認するには、crash ユーティリティーを使用します。これにより、GDB (GNU Debugger) と非常によく似たインタラクティブなプロンプトを利用できます。このユーティリティーを使用すると、実行中の Linux システムおよび netdumpdiskdumpxendump、または kdump によって作成されるコアダンプを対話形式で分析できます。

7.6.1. crash ユーティリティーのインストール

crash 分析ツールをインストールするには、 root でシェルプロンプトから以下のコマンドを実行します。

yum install crash

crash に加え、実行中のカーネルに対応する kernel-debuginfo パッケージもインストールしておく必要があります。kernel-debuginfo をインストールするには、debuginfo-install コマンドを root で使用します。

debuginfo-install kernel

Yum を使用した Red Hat Enterprise Linux の新規パッケージのインストール方法については『Red Hat Enterprise Linux 7 システム管理者のガイド』を参照してください。

7.6.2. crash ユーティリティーの実行

シェルプロンプトで次の形式のコマンドを入力してユーティリティーを起動します。

crash /usr/lib/debug/lib/modules/<kernel>/vmlinux \ /var/crash/<timestamp>/vmcore

kdump で取得したのと同じ <kernel> のバージョンを使用します。現在実行中のカーネルを判別するには、uname -r コマンドを使用します。

例7.1 crash ユーティリティーの実行

~]# crash /usr/lib/debug/lib/modules/2.6.32-69.el6.i686/vmlinux \
/var/crash/127.0.0.1-2010-08-25-08:45:02/vmcore

crash 5.0.0-23.el6
Copyright (C) 2002-2010  Red Hat, Inc.
Copyright (C) 2004, 2005, 2006  IBM Corporation
Copyright (C) 1999-2006  Hewlett-Packard Co
Copyright (C) 2005, 2006  Fujitsu Limited
Copyright (C) 2006, 2007  VA Linux Systems Japan K.K.
Copyright (C) 2005  NEC Corporation
Copyright (C) 1999, 2002, 2007  Silicon Graphics, Inc.
Copyright (C) 1999, 2000, 2001, 2002  Mission Critical Linux, Inc.
This program is free software, covered by the GNU General Public License,
and you are welcome to change it and/or distribute copies of it under
certain conditions.  Enter "help copying" to see the conditions.
This program has absolutely no warranty.  Enter "help warranty" for details.

GNU gdb (GDB) 7.0
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...

      KERNEL: /usr/lib/debug/lib/modules/2.6.32-69.el6.i686/vmlinux
    DUMPFILE: /var/crash/127.0.0.1-2010-08-25-08:45:02/vmcore  [PARTIAL DUMP]
        CPUS: 4
        DATE: Wed Aug 25 08:44:47 2010
      UPTIME: 00:09:02
LOAD AVERAGE: 0.00, 0.01, 0.00
       TASKS: 140
    NODENAME: hp-dl320g5-02.lab.bos.redhat.com
     RELEASE: 2.6.32-69.el6.i686
     VERSION: #1 SMP Tue Aug 24 10:31:45 EDT 2010
     MACHINE: i686  (2394 Mhz)
      MEMORY: 8 GB
       PANIC: "Oops: 0002 [#1] SMP " (check log for details)
         PID: 5591
     COMMAND: "bash"
        TASK: f196d560  [THREAD_INFO: ef4da000]
         CPU: 2
       STATE: TASK_RUNNING (PANIC)

crash>

7.6.3. メッセージバッファーの表示

カーネルメッセージバッファーを表示するには、対話式プロンプトで log コマンドを入力します。

例7.2 カーネルメッセージバッファーの表示

crash> log
... several lines omitted ...
EIP: 0060:[<c068124f>] EFLAGS: 00010096 CPU: 2
EIP is at sysrq_handle_crash+0xf/0x20
EAX: 00000063 EBX: 00000063 ECX: c09e1c8c EDX: 00000000
ESI: c0a09ca0 EDI: 00000286 EBP: 00000000 ESP: ef4dbf24
 DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
Process bash (pid: 5591, ti=ef4da000 task=f196d560 task.ti=ef4da000)
Stack:
 c068146b c0960891 c0968653 00000003 00000000 00000002 efade5c0 c06814d0
<0> fffffffb c068150f b7776000 f2600c40 c0569ec4 ef4dbf9c 00000002 b7776000
<0> efade5c0 00000002 b7776000 c0569e60 c051de50 ef4dbf9c f196d560 ef4dbfb4
Call Trace:
 [<c068146b>] ? __handle_sysrq+0xfb/0x160
 [<c06814d0>] ? write_sysrq_trigger+0x0/0x50
 [<c068150f>] ? write_sysrq_trigger+0x3f/0x50
 [<c0569ec4>] ? proc_reg_write+0x64/0xa0
 [<c0569e60>] ? proc_reg_write+0x0/0xa0
 [<c051de50>] ? vfs_write+0xa0/0x190
 [<c051e8d1>] ? sys_write+0x41/0x70
 [<c0409adc>] ? syscall_call+0x7/0xb
Code: a0 c0 01 0f b6 41 03 19 d2 f7 d2 83 e2 03 83 e0 cf c1 e2 04 09 d0 88 41 03 f3 c3 90 c7 05 c8 1b 9e c0 01 00 00 00 0f ae f8 89 f6 <c6> 05 00 00 00 00 01 c3 89 f6 8d bc 27 00 00 00 00 8d 50 d0 83
EIP: [<c068124f>] sysrq_handle_crash+0xf/0x20 SS:ESP 0068:ef4dbf24
CR2: 0000000000000000

このコマンドの使用方法についての詳細を確認するには、 help log を入力します。

注記

カーネルメッセージバッファーには、システムクラッシュに関する最も重要な情報が含まれています。したがって、これは常に最初に vmcore-dmesg.txt ファイルにダンプされます。これは、たとえば、ターゲットの場所にスペースがないために、vmcore ファイル全体の取得の試行に失敗する場合に便利です。デフォルトで、vmcore-dmesg.txt/var/crash/ ディレクトリーにあります。

7.6.4. バックトレースの表示

カーネルスタックトレースを表示するには、対話式プロンプトで bt コマンドを入力します。bt <pid> を使用して、単一プロセスのバックトレースを表示できます。

例7.3 カーネルスタックトレースの表示

crash> bt
PID: 5591   TASK: f196d560  CPU: 2   COMMAND: "bash"
 #0 [ef4dbdcc] crash_kexec at c0494922
 #1 [ef4dbe20] oops_end at c080e402
 #2 [ef4dbe34] no_context at c043089d
 #3 [ef4dbe58] bad_area at c0430b26
 #4 [ef4dbe6c] do_page_fault at c080fb9b
 #5 [ef4dbee4] error_code (via page_fault) at c080d809
    EAX: 00000063  EBX: 00000063  ECX: c09e1c8c  EDX: 00000000  EBP: 00000000
    DS:  007b      ESI: c0a09ca0  ES:  007b      EDI: 00000286  GS:  00e0
    CS:  0060      EIP: c068124f  ERR: ffffffff  EFLAGS: 00010096
 #6 [ef4dbf18] sysrq_handle_crash at c068124f
 #7 [ef4dbf24] __handle_sysrq at c0681469
 #8 [ef4dbf48] write_sysrq_trigger at c068150a
 #9 [ef4dbf54] proc_reg_write at c0569ec2
#10 [ef4dbf74] vfs_write at c051de4e
#11 [ef4dbf94] sys_write at c051e8cc
#12 [ef4dbfb0] system_call at c0409ad5
    EAX: ffffffda  EBX: 00000001  ECX: b7776000  EDX: 00000002
    DS:  007b      ESI: 00000002  ES:  007b      EDI: b7776000
    SS:  007b      ESP: bfcb2088  EBP: bfcb20b4  GS:  0033
    CS:  0073      EIP: 00edc416  ERR: 00000004  EFLAGS: 00000246

このコマンドの使用方法についての詳細を確認するには、 help bt を入力します。

7.6.5. プロセスの状態表示

システム内のプロセスのステータスを表示するには、対話式プロンプトで ps コマンドを入力します。単一プロセスのステータスを表示するには、ps <pid> を使用できます。

例7.4 システム内のプロセスの状態表示

crash> ps
   PID    PPID  CPU   TASK    ST  %MEM     VSZ    RSS  COMM
>     0      0   0  c09dc560  RU   0.0       0      0  [swapper]
>     0      0   1  f7072030  RU   0.0       0      0  [swapper]
      0      0   2  f70a3a90  RU   0.0       0      0  [swapper]
>     0      0   3  f70ac560  RU   0.0       0      0  [swapper]
      1      0   1  f705ba90  IN   0.0    2828   1424  init
... several lines omitted ...
   5566      1   1  f2592560  IN   0.0   12876    784  auditd
   5567      1   2  ef427560  IN   0.0   12876    784  auditd
   5587   5132   0  f196d030  IN   0.0   11064   3184  sshd
>  5591   5587   2  f196d560  RU   0.0    5084   1648  bash

このコマンドの使用方法についての詳細を確認するには、 help ps を入力します。

7.6.6. 仮想メモリー情報の表示

基本的な仮想メモリーの情報を表示するには、対話式プロンプトで vm コマンドを入力します。vm <pid> を使用して、単一プロセスの情報を表示できます。

例7.5 現在のコンテキストの仮想メモリー情報の表示

crash> vm
PID: 5591   TASK: f196d560  CPU: 2   COMMAND: "bash"
   MM       PGD      RSS    TOTAL_VM
f19b5900  ef9c6000  1648k    5084k
  VMA       START      END    FLAGS  FILE
f1bb0310    242000    260000 8000875  /lib/ld-2.12.so
f26af0b8    260000    261000 8100871  /lib/ld-2.12.so
efbc275c    261000    262000 8100873  /lib/ld-2.12.so
efbc2a18    268000    3ed000 8000075  /lib/libc-2.12.so
efbc23d8    3ed000    3ee000 8000070  /lib/libc-2.12.so
efbc2888    3ee000    3f0000 8100071  /lib/libc-2.12.so
efbc2cd4    3f0000    3f1000 8100073  /lib/libc-2.12.so
efbc243c    3f1000    3f4000 100073
efbc28ec    3f6000    3f9000 8000075  /lib/libdl-2.12.so
efbc2568    3f9000    3fa000 8100071  /lib/libdl-2.12.so
efbc2f2c    3fa000    3fb000 8100073  /lib/libdl-2.12.so
f26af888    7e6000    7fc000 8000075  /lib/libtinfo.so.5.7
f26aff2c    7fc000    7ff000 8100073  /lib/libtinfo.so.5.7
efbc211c    d83000    d8f000 8000075  /lib/libnss_files-2.12.so
efbc2504    d8f000    d90000 8100071  /lib/libnss_files-2.12.so
efbc2950    d90000    d91000 8100073  /lib/libnss_files-2.12.so
f26afe00    edc000    edd000 4040075
f1bb0a18   8047000   8118000 8001875  /bin/bash
f1bb01e4   8118000   811d000 8101873  /bin/bash
f1bb0c70   811d000   8122000 100073
f26afae0   9fd9000   9ffa000 100073
... several lines omitted ...

このコマンドの使用方法についての詳細を確認するには、 help vm を入力します。

7.6.7. オープンファイルの表示

開かれたファイルについての情報を表示するには、対話式プロンプトで files コマンドを入力します。files <pid> を使用して、選択された 1 つのプロセスによってのみ開かれているファイルを表示できます。

例7.6 現在のコンテキストのオープンファイルについての情報の表示

crash> files
PID: 5591   TASK: f196d560  CPU: 2   COMMAND: "bash"
ROOT: /    CWD: /root
 FD    FILE     DENTRY    INODE    TYPE  PATH
  0  f734f640  eedc2c6c  eecd6048  CHR   /pts/0
  1  efade5c0  eee14090  f00431d4  REG   /proc/sysrq-trigger
  2  f734f640  eedc2c6c  eecd6048  CHR   /pts/0
 10  f734f640  eedc2c6c  eecd6048  CHR   /pts/0
255  f734f640  eedc2c6c  eecd6048  CHR   /pts/0

このコマンドの使用方法についての詳細を確認するには、 help files を入力します。

7.6.8. ユーティリティーの終了

対話式プロンプトを終了し、crash を終了するには、exit または q を入力します。

例7.7 crash ユーティリティーの終了

crash> exit
~]#

7.7. よくある質問

クラスター化された環境で kdump を使用する場合には、何に注意したら良いですか?

RHEL 6 および 7 の High Availability アドオンで使用できるように kdump を設定する」の記事で、High Availability アドオンを使用しているシステム管理者が利用可能なオプションを説明しています。

起動初期に kdump が失敗します。 どのようにしてブートログをキャプチャーするのですか?

2 番目のカーネルの起動に問題がある場合は、起動初期のブートログを確認する必要があります。 問題のあるマシンに対するシリアルコンソールを有効にすることで、このログを取得することができます。

RHEL7 でシリアルターミナルを設定する」の記事で、起動初期のブートメッセージへアクセスするために必要な設定が説明されています。

デバッグ用に、どのようにして makedumpfile からのメッセージを増やすのですか?

makedumpfile が失敗する場合は、問題点を把握するためにログのレベルを引き上げる必要があります。これはダンプレベルの設定とは異なり、core_collector 行エントリーで /etc/kdump.conf を編集し、 message_level オプション makedumpfile に対して引き上げて実行します。

デフォルトで makedumpfile はレベル 1 に設定されており、これは、出力を進捗インジケーターに制限します。このメッセージレベルを 31 に設定すると、すべてのデバッグ情報を有効にできます。メッセージレベル 31 では、進捗インジケーター、共通メッセージ、エラーメッセージ、デバッグメッセージ、およびレポートメッセージの詳細を出力します。

注記

メッセージレベルのオプションの詳細は、makedumpfile (8) man ページを参照してください。

core_collector 設定の行は、設定時には以下のようになっているはずです。

core_collector makedumpfile -l --message-level 1 -d 31

どのようにして Dracut をデバッグするのですか?

dracut は initramfs のビルドに失敗する場合があります。失敗する場合は、問題を切り分けるために dracut のログレベルを引き上げます。

/etc/kdump.conf を編集し、 dracut_args 行を、必要なすべての dracut 引数と共にオプションの -L 5 を含めるように変更します。

dracut_args に他のオプションが設定されていない場合、結果は以下のようになります。

dracut_args -L 5

仮想マシンで利用可能なダンプの手法は何ですか?

多くの場合、クラッシュやパニックの後にマシンからメモリーダンプを取得するには、kdump の仕組みがあれば十分です。これは、ベアメタルのインストールと同じように設定することができます。

ただし、場合によっては、ハイパーバイザーと直接連携してクラッシュダンプを取得する必要がある場合があります。これを実行するために、libvirt で 2 つの仕組みを使用できます。それらは pvpanic および virsh dump です。これらの手法は 『仮想化の導入および管理ガイド』 に記載されています。

pvpanic の仕組みについては、『仮想化の導入および管理ガイド』の「パニックデバイスの設定」に記載されています。

virsh dump コマンドについては、『仮想化の導入および管理ガイド』の「ドメインのコアのダンプファイルの作成」で説明されています。

Red Hat サポートサービスに大きなサイズのダンプをアップロードする場合はどうしたらいいですか ?

分析のため、Red Hat グローバルサポートサービスにカーネルクラッシュのダンプファイルを送信していただく必要がある場合があります。ただし、ダンプファイルのサイズはフィルターで特定の情報に絞り込んだ場合でも非常に大きくなる可能性があります。新しいサポートケースの起票時に、250 MB を超えるファイルは Red Hat カスタマーポータルからは直接アップロードできないため、Red Hat では大きなサイズのファイルのアップロード用に FTP サーバーを用意しています。

FTP サーバーのアドレスは dropbox.redhat.com で、ファイルは /incoming/ ディレクトリーにアップロードされます。ご使用の FTP クライアントを passive モードに設定しておく必要があります。 ご使用のファイアウォールでこのモードを使用できない場合は、origin-dropbox.redhat.com サーバーを active モードで使用してください。

アップロードするファイルは必ず gzip などで圧縮し、ファイル名にはわかりやすい名前を付けてください。ファイル名にサポートケース番号を使用されることをお薦めします。必要なファイルをすべてアップロードしたらサポートケース担当のエンジニアへ正確なファイル名とその SHA1 または MD5 チェックサムをお知らせください。

詳細な説明については「Ret Hat サポートチームにファイル (vmcore、rhev logcollector、sosreport、ヒープダンプ、ログファイルなど) を送付する」を参照ください。

クラッシュダンプが完了するまでに、どれくらい時間がかかりますか?

この情報は、障害復旧計画の目的で、ダンプ完了の所要時間を把握するために、多くの場合に必要となります。ただし、この時間の長さは、ディスクにコピーされるメモリー量と、RAM とストレージ間のインターフェースの速度に大きく左右されます。

テストがどのようなタイミングで行われても、システムは典型的な負荷をかけた状態で稼働させておく必要があります。そうでないと、除外されるページによって、完全に負荷がかかった実稼働システムにおける kdump の動作で誤った見解が提示される可能性があります。特にこの違いは、大量のメモリーが使用されている状況でより顕著に見られます。

ダンプの所要時間を評価する場合に、ストレージインターフェースもプランニング時に考慮する必要があります。ネットワーク制約事項が原因で、ローカルに接続された SATA ディスクと比べると、ssh などを使用した接続ダンプは完了までに長く時間がかかる可能性があります。

インストール時に Kdump をどのように設定するのですか?

キックスタートまたは対話型の GUI を使用すれば、わずかなオプションを指定するだけでインストール時に kdump を設定することができます。

anaconda インストール GUI を使用した kdump の設定については、『インストールガイド』の「Kdump」セクションに詳しい説明が記載されています。

kickstart 構文は以下の通りです。

%addon com_redhat_kdump [--disable,enable] [--reserve-mb=[auto,value]]
%end

キックスタートに対するこのアドオンにより、kdump 機能の無効化/有効化や、オプションとして予約メモリーサイズの定義 (自動のデフォルトオプションを明示的に呼び出す、またはメガバイト単位で数値を指定する) が可能になります。 なお、スイッチ全体が省略された場合も、デフォルトオプションが呼び出されます。

キックスタートを使用してシステムのデプロイメントを自動化する方法の詳細は、『インストールガイド』の「キックスタートを使ったインストール」を参照してください。

キックスタートアドオン構文の詳細については、『インストールガイド』の「キックスタート構文の参考資料」を参照してください。

7.8. サポートしている kdump の設定とダンプ出力先

7.8.1. kdump メモリー要件

kdump でカーネルクラッシュダンプをキャプチャーしてさらに分析ができるように保存するにはシステムメモリーの一部をキャプチャーカーネル用に永続的に予約する必要があります。

コマンドラインでメモリー設定を変更する方法は、「メモリー使用量の設定」を参照してください。グラフィカルユーザーインターフェースで予約メモリーの設定を変更する方法については 「メモリー使用量の設定」 を参照してください。

表 7.1 では、CPU アーキテクチャーに基づく kdump の最小メモリー要件と、RHEL 7 バージョンを含む kernel パッケージで利用可能な物理メモリーの合計を一覧表示しています。

表7.1 kernel パッケージで kdump 用に必要な最小メモリー

アーキテクチャー使用可能なメモリー最小予約メモリー

AMD64 および Intel 64 (x86_64)

2 GB より小さい

0 MB の RAM

2 GB 以上

161 MB + 64 MB (1 TB の RAM あたり)

RHEL 7.4 における 64 ビット ARM アーキテクチャー (arm64)

該当なし

512 MB の RAM

RHEL 7.5 における 64 ビット ARM アーキテクチャー (arm64)

2GB 未満

0 MB の RAM

2 GB 以上

512 MB の RAM

IBM POWER (ppc64)

2 GB より小さい

0 MB の RAM

2 GB から 4 GB

384 MB のメモリー

4 GB から 16 GB

512 GB の RAM

16 GB から 64 GB

1 GB のメモリー

64 GB から 128 GB

2 GB のメモリー

128 GB 以上

4 GB の RAM

IBM Z (s390x)

4 GB より小さい

0 MB の RAM

4 GB 以上

161 MB + 64 MB (1 TB の RAM あたり)

表 7.2 では、CPU アーキテクチャーに基づく kdump の最小メモリー要件と、RHEL 7.4 および 7.5 バージョンを含む kernel-alt パッケージで利用可能な物理メモリーの合計を一覧表示しています。

表7.2 kernel-alt パッケージで kdump 用に必要な最小メモリー

アーキテクチャー使用可能なメモリー最小予約メモリー

64 ビット ARM アーキテクチャー (arm64)

2 GB より小さい

0 MB の RAM

2 GB 以上

512 MB の RAM

IBM POWER (ppc64`and `ppc64le)

2 GB より小さい

0 MB の RAM

2 GB から 4 GB

384 MB のメモリー

4 GB から 16 GB

512 GB の RAM

16 GB から 64 GB

1 GB のメモリー

64 GB から 128 GB

2 GB のメモリー

128 GB 以上

4 GB の RAM

さまざまな Red Hat Enterprise Linux テクノロジーの機能や制限に関する詳しい情報は、https://access.redhat.com/articles/rhel-limits を参照してください。

7.8.2. メモリー自動予約の最小しきい値

一部のシステムでは、ブートローダーの設定ファイルで crashkernel=auto パラメーターを使用するか、またはグラフィカル設定ユーティリティーで自動割り当ての設定を有効にすると、kdump 用のメモリーを自動的に割り当てることができます。ただし、この自動予約が機能するには、合計メモリーの特定量のメモリーを利用できる必要があります。この容量はシステムのアーキテクチャーによって異なります。

次の表は、自動メモリー割り当てのしきい値の一覧です。システムのメモリーが以下に示すしきい値を下回る場合は手動でメモリー予約を行う必要があります。

コマンドラインで設定を変更する方法については 「メモリー使用量の設定」 を参照してください。グラフィカルユーザーインターフェースで予約メモリーのサイズを変更する方法については 「メモリー使用量の設定」 を参照してください。

表7.3 自動メモリー予約に必要な最小メモリーサイズ

アーキテクチャー必要なメモリー

AMD64 および Intel 64 (x86_64)

2 GB

IBM POWER (ppc64)

2 GB

IBM Z (s390x)

4 GB

7.8.3. サポートしている kdump のダンプ出力先

カーネルクラッシュをキャプチャーする際、コアダンプを直接デバイスに書き込んでローカルファイルシステムにファイルとして保存するか、またはネットワーク経由で送信することができます。現在サポートしているダンプ出力先および kdump による非サポートが明確なダンプ出力先の全一覧を以下に示します。

コマンドラインでターゲットタイプを設定する方法は、「kdump タイプの設定」を参照してください。グラフィカルユーザーインターフェースでデフォルト動作を設定する方法については 「kdump タイプの設定」 を参照してください。

表7.4 対応している kdump のダンプ出力先

Type対応しているダンプ出力先対応していないダンプ出力先

Raw デバイス

ローカルで添付されたすべての raw ディスクとパーティション

 

ローカルファイルシステム

直接接続されているディスクドライブ、ハードウェア RAID 論理ドライブ、LVM デバイス、mdraid アレイ上の ext2ext3ext4、および xfs ファイルシステム。

auto タイプ (自動ファイルシステム検出) など、この表で明示的にサポート対象とされていないローカルファイルシステム。

リモートディレクトリー

IPv4NFS または SSH プロトコルを使用してアクセスするリモートディレクトリー。

NFS プロトコルを使用してアクセスする rootfs ファイルシステム上のリモートディレクトリー。

FCoE (Fibre Channel over Ethernet) プロトコルを使用してアクセスするリモートディレクトリー。

qla2xxxlpfc および bfa ハードウェアの FCoE ターゲット。bnx2fc および ixgbe ソフトウェアの FCoE ターゲット。

 

ハードウェアおよびソフトウェアイニシエーター上で iSCSI プロトコルを使用してアクセスするリモートディレクトリー。

be2iscsi ハードウェアで iSCSI プロトコルを使用してアクセスするリモートディレクトリー。

マルチパスベースのストレージ

 

IPv6 上でアクセスするリモートディレクトリー。

 

SMB または CIFS プロトコルを使用してアクセスするリモートディレクトリー。

 

ワイヤレスネットワークインターフェースを使ってアクセスするリモートディレクトリー

注記

ソフトウェア FCoE のダンプ出力先へダンプすると、OOM (Out of Memory) エラーが発生します。この場合は、デフォルトの crashkernel=auto パラメーターの値を大きくします。このカーネルブートパラメーターを設定する方法は 「メモリー使用量の設定」 を参照してください。

7.8.4. 対応している kdump のフィルターレベル

ダンプファイルのサイズを縮小するには、kdump は makedumpfile コアコレクターを使用してデータを圧縮し、オプションで関連性のない情報を除外します。以下の表には、makedumpfile ユーティリティーで現在対応しているフィルターレベルの詳細な一覧を示します。

コマンドラインでコアコレクターを設定する方法は、「コアコレクターの設定」を参照してください。グラフィカルユーザーインターフェースでデフォルト動作を設定する方法については 「コアコレクターの設定」 を参照してください。

表7.5 サポートしているフィルターレベル

オプション詳細

1

ゼロページ

2

キャッシュページ

4

キャッシュプライベート

8

ユーザーページ

16

フリーページ

注記

makedumpfile コマンドは、Red Hat Enterprise Linux 7.3 以降の透過的な Huge Page および hugetlbfs ページの削除をサポートします。これらのどうちらのタイプの hugepages User Page も考慮し、これらを -8 レベルを使用して削除します。

7.8.5. サポートしているデフォルトの動作

kdump がコアダンプの作成に失敗すると、デフォルトでは、オペレーティングシステムが再起動します。第 1 ダンプ出力先へのコアダンプの保存に失敗した場合、kdump に別の動作を行うよう設定することができます。kdump で現在サポートしているデフォルト動作を以下に示します。

コマンドラインでデフォルト動作を設定する方法については 「デフォルト動作の設定」 を参照してください。グラフィカルユーザーインターフェースでデフォルト動作を設定する方法については 「デフォルト動作の設定」 を参照してください。

表7.6 サポートしているデフォルトの動作

オプション詳細

dump_to_rootfs

root ファイルシステムにコアダンプの保存を試行します。ネットワーク上のダンプ出力先と併用する場合に特に便利なオプションです。ネットワーク上のダンプ出力先にアクセスできない場合、ローカルにコアダンプを保存するよう kdump の設定を行います。システムは、後で再起動します。

reboot

システムを再起動します。コアダンプは失われます。

halt

システムを停止します。コアダンプは失われます。

poweroff

システムの電源を切ります。コアダンプは失われます。

shell

initramfs 内から shell セッションを実行して、ユーザーが手動でコアダンプを記録できるようにします。

7.8.6. kdumpサイズの見積もり

kdump 環境のプランニングや構築の際に、ダンプファイルに必要な容量がどれくらいか把握してからこれを作成する必要があります。makedumpfile コマンドは、これを実行する際に役立ちます。

以下のように、--mem-usage 機能を使用して、ダンプファイルに必要な領域を見積もります。

# makedumpfile -f --mem-usage /proc/kcore

注記

-f オプションを使用した --mem-usage 機能は、カーネルバージョン v4.11 以降で動作します。

v4.11 よりも前のバージョンのカーネルでは、--mem-usage をオプション -f を指定して使用する前に、カーネルにアップストリームのコミット 464920104bf7 でパッチが適用されていることを確認します。

--mem-usage オプションでは、除外可能なページに関する有用なレポートが提供され、これを使用して、割り当てるダンプレベルを判断することができます。このコマンドは、システムに通常の負荷をかけた状態で実行する必要があります。そうでない場合に、makedumpfile は実稼働環境で必要とされる値よりも小さい値を返します。

[root@hostname ~]# makedumpfile -f --mem-usage /proc/kcore

TYPE            PAGES                   EXCLUDABLE      DESCRIPTION
----------------------------------------------------------------------
ZERO            501635                  yes             Pages filled with zero
CACHE           51657                   yes             Cache pages
CACHE_PRIVATE   5442                    yes             Cache pages + private
USER            16301                   yes             User process pages
FREE            77738211                yes             Free pages
KERN_DATA       1333192                 no              Dumpable kernel data
重要

makedumpfile コマンドは pages にレポートを出します。つまり、カーネルページサイズ (Red Hat Enterprise Linux カーネルの場合、AMD64 および Intel 64 のアーキテクチャーでは 4 キロバイト、IBM POWER アーキテクチャーの場合は 64 キロバイト) に対して使用中のメモリーのサイズを計算する必要があります。

7.9. kexec を使用したカーネルの再起動

7.9.1. kexec によるカーネルの再起動

kexec システムコールを使用すると現在実行中のカーネルから別のカーネルを読み込んだり、起動したりすることが可能で、カーネル内のブートローダーとして機能します。

kexec ユーティリティーは、kexec システムコールのカーネルおよび initramfs イメージを読み込み、別のカーネルで起動します。

以下のセクションでは、`kexec` ユーティリティーを使用して別のカーネルで再起動する際に kexec システムコールを手動で呼び出す方法を説明します。

  1. kexec ユーティリティーを実行します。

    # kexec -l /boot/vmlinuz-3.10.0-1040.el7.x86_64 --initrd=/boot/initramfs-3.10.0-1040.el7.x86_64.img --reuse-cmdline

    このコマンドは、kexec システムコールのカーネルおよび initramfs イメージを手動で読み込みます。

  2. システムを再起動します。

    # reboot

    このコマンドはカーネルを検出し、すべてのサービスをシャットダウンしてから、kexec システムコールを呼び出して直前の手順で指定したカーネルに再起動します。

警告

kexec -e コマンドを使用してカーネルを再起動すると、システムは、次のカーネルを起動する前に標準のシャットダウンシーケンスを通過しません。そのため、データ損失や応答しないシステムが発生する可能性があります。

7.10. kdump に関連する Portal Labs

Portal Labs は簡単な Web アプリケーションで、システム管理者がさまざまなシステムタスクを実施するのに役立ちます。現在、Kdump に焦点を当てているラボが 2 つあります。Kdump Helper および Kernel Oops Analyzer

7.10.1. Kdump ヘルパー

Kdump Helper は、一連の質問および操作で構成され、kdump の設定ファイルの準備を支援します。

Lab のワークフローには、クラスター化された環境およびスタンドアロン環境の両方に関する手順が含まれています。

7.10.2. Kernel Oops Analyzer

Kernel Oops Analyzer ツールを使うと、Oops メッセージを処理して、クラッシュダンプスタックを解析することなく既知のソリューションがあるかどうかを確認することができます。

Kernel Oops Analyzer では、makedumpfile からの情報を使用し、クラッシュしたマシンの Oops メッセージとナレッジベースの既知の問題を比較します。これにより、予期せぬ障害が発生しても、システム管理者はすばやく既知の問題の可能性を除外して、詳細な解析を依頼するためにサポートチケットを発行することができます。


このページには機械翻訳が使用されている場合があります (詳細はこちら)。