第1章 カーネルクラッシュダンプガイド
1.1. kdump について
1.1.1. kdump と kexec について
kdump とは、システムのメモリー内容を保存して後で分析できるようにカーネルのクラッシュをダンプする仕組みを指します。kdump は kexec に依存し、この kexec を使用して、別のカーネルのコンテキストから Linux カーネルを起動し、BIOS を迂回して通常は失われてしまう 1 番目のカーネルメモリーの内容を保持することができます。
システムクラッシュが発生すると kdump は kexec を使用して 2 番目のカーネルで起動します (キャプチャーカーネル)。この 2 番目のカーネルはシステムメモリーの予約部分に収納されていて 1 番目のカーネルからはアクセスできません。2 番目のカーネルは起動するとクラッシュしたカーネルメモリーの内容 (クラッシュダンプ) をキャプチャーして保存します。
カーネルクラッシュダンプは、障害時に唯一利用可能な情報である可能性があるので、ビジネスに不可欠な環境ではこのデータの重要性を過小評価してはいけません。Red Hat は、システム管理者に対して、通常のカーネル更新サイクルで kexec-tools を定期的に更新、テストすることを推奨します。これは、新しいカーネル機能が実装された場合に特に重要です。
1.1.2. メモリーの要件
kdump でカーネルクラッシュのダンプをキャプチャーして分析のため保存するにはキャプチャーカーネル用にシステムメモリーの一部を永続的に予約しておく必要があります。予約するとその部分はメインカーネルでは使用できなくなります。
メモリーの要件は、特定のシステムパラメーターにより異なります。主な要因の 1 つとして、システムのハードウェアアーキテクチャーが挙げられます。次のコマンドをシェルプロンプトで入力してマシンの正確なアーキテクチャー名を特定し (x86_64 など)、標準出力に表示させます。
uname -m予約すべきメモリーサイズを左右する別の要因として搭載しているシステムメモリーの総量が影響します。たとえば、x86_64 アーキテクチャーでは予約メモリーは 4 KB のメモリーごとに、160 MB + 2 ビットになります。搭載されている物理メモリーの合計が 1 TB のシステムの場合には 224 MB (160 MB + 64 MB) ということになります。システムアーキテクチャーごとの kdump メモリー要件と物理メモリー量についての詳細は 「kdump メモリー要件」 を参照してください。
多くのシステムでは必要なメモリー量は kdump によって自動的に算出、予約が行われます。この動作はデフォルトで有効になっていますが、利用可能な合計メモリーサイズが一定以上搭載されているシステムに限られます。この自動割り当て動作に必要なメモリーサイズはシステムのアーキテクチャーによって異なります。「メモリー自動予約の最小しきい値」 に自動メモリー割り当てに必要な最小メモリーサイズの一覧をシステムアーキテクチャーごとに示します。
システムメモリーが自動割り当ての動作に必要な最小メモリーに満たない場合、または独自の予約メモリーサイズを必要とするような場合には予約メモリーを手動で設定することができます。コマンドラインでこの作業を行う場合は 「メモリー使用量の設定」 を参照してください。グラフィカルユーザーインターフェースでこの作業を行う場合は 「メモリー使用量の設定」 を参照してください。
kdump サービスを設定したら、自動メモリー割り当てであっても設定のテストを行うことを強く推奨します。設定のテスト方法については 「kdump 設定のテスト」 を参照してください。
1.2. kdump のインストールと設定
1.2.1. kdump のインストール
多くの場合、Red Hat Enterprise Linux 7 の新規インストールで kdump サービスはデフォルトでインストールされます。グラフィカルインターフェースまたはテキストインターフェースを使って対話形式でインストールする場合には、Anaconda インストーラーに kdump の設定画面があります。インストーラーの画面には kdump というタイトルが付けられ、メイン画面の インストールの概要 からアクセスすることができます。設定については制限があり、ここで選択できるのは 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
この他、グラフィカルな設定ツールもあります。ただし上記のコマンドを使った場合に、デフォルトではグラフィカルな設定ツールはインストールされません。グラフィカルな設定ツールをインストールする場合は次のコマンドを root で実行します。グラフィカルな設定ツールの詳細は 「グラフィカルユーザーインターフェースでの kdump の設定」 を参照してください。
# yum install system-config-kdumpYum を使用した Red Hat Enterprise Linux 7 の新規パッケージのインストール方法については『Red Hat Enterprise Linux 7 システム管理者のガイド』を参照してください。
Red Hat Enterprise Linux 7.4 から、kdump は Intel IOMMU ドライバーをサポートしています。7.3 以前のバージョンのカーネルを実行する場合は、Intel IOMMU のサポートを無効にすることを推奨します。
1.2.2. コマンドライン上での kdump の設定
1.2.2.1. メモリー使用量の設定
kdump カーネル用に予約されるメモリーは必ずシステムの起動時にその予約が行われます。つまり、メモリーのサイズはシステムのブートローダー設定で指定されています。
kdump カーネル用に割り当てるメモリーを指定するには、crashkernel= オプションを必要な値に設定します。たとえば、128 MB のメモリーを割り当てるには、以下を使用します。
crashkernel=128M
AMD64 および Intel 64 システム、IBM Power SYstems サーバーでは GRUB2 ブートローダーを使用し、IBM System z では zipl を使用して crashkernel= オプションを変更する方法は、「カーネルコマンドラインパラメーターの設定」 を参照してください。
crashkernel= オプションの指定方法は数種類あります。auto の値を使用すると 「kdump メモリー要件」 に記載したガイドラインに沿ってシステムのメモリー合計に基づいた予約メモリーが自動設定されます。メモリーサイズが大きいシステムで、crashkernel=auto オプションが指定されている場合には、 オペレーティングシステムに設定された上限まで 、<link to OS Limits> が算出されます。
この動作を変更するには、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)。
1.2.2.2. kdump タイプの設定
カーネルクラッシュをキャプチャーする場合に、コアダンプは、ローカルファイルシステムにファイルとして格納するか、デバイスに直接書き込むか、NFS (Network File System) または SSH (Secure Shell) のプロトコルを使用してネットワークで送信することが可能です。現時点で設定できるのは、これらのオプションのうちの 1 つのみである点に注意してください。デフォルトのオプションは、vmcore ファイルをローカルファイルシステムの /var/crash/ ディレクトリー内に格納する方法です。このオプションを変更するには、root としてテキストエディターで /etc/kdump.conf 設定ファイルを開き、以下のようにオプションを編集します。
コアダンプの保存先のローカルディレクトリーを変更する場合は #path /var/crash の行頭にあるハッシュ記号 (#) を取り除き、値を変更先のディレクトリーパスに置き換えます。
path /usr/local/cores
Red Hat Enterprise Linux 7 では kdump のダンプ出力先として path ディレクティブで指定されているディレクトリーが kdump systemd サービスの起動時に存在していなければなりません。起動時にこのディレクトリーが存在していないとサービスの起動は失敗します。この動作は Red Hat Enterprise Linux の以前のリリースと異なります。以前のリリースではサービスの起動時にこのディレクトリーが存在していないと自動的に作成されていました。
オプションで、ファイルを別のパーティションに書き込む場合は、#ext4 で始まる行のハッシュ記号を取り除き、値を変更先のディレクトリーパスに置き換えます。値にはデバイス名 (#ext4 /dev/vg/lv_kdump 行)、ファイルシステムのラベル (#ext4 LABEL=/boot 行)、UUID (#ext4 UUID=03138356-5e61-4ab3-b58e-27507ac41937 行) のいずれかを使用できます。例を示します。
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 システム管理者のガイド』を参照してください。
サポートしているダンプ出力先と非サポートのダンプ出力先のタイプ別一覧は 表1.3「サポートしている kdump のダンプ出力先」を参照してください。
1.2.2.3. コアコレクターの設定
vmcore ダンプファイルのサイズを小さくするために、kdump では外部アプリケーション (core collector) を指定して、データの圧縮や必要に応じた関連性のないすべての情報の除外ができます。現在、完全サポートしているコアコレクターは makedumpfile のみになります。
コアコレクターを有効にするには、root として、テキストエディターで /etc/kdump.conf 設定ファイルを開いて、#core_collector makedumpfile -l --message-level 1 -d 31 の行頭にあるハッシュ記号 (#) を取り除き、以下の説明通りにコマンドラインのオプションを編集します。
ダンプファイルの圧縮を有効にするには、-c パラメーターを追加します。例を示します。
core_collector makedumpfile -c
ダンプから特定のページを除外するには、-d value を追加します。value には 表1.4「サポートしているフィルターレベル」で説明しているように、省略するページの値の合計を入力します。ゼロと未使用ページを除外する場合は次のようになります。
core_collector makedumpfile -d 17 -c
使用できるオプションの一覧については makedumpfile(8) の man ページを参照してください。
1.2.2.4. デフォルト動作の設定
kdump が 「kdump タイプの設定」 で指定したダンプ出力先でのコアダンプの作成に失敗すると、デフォルトではルートファイルシステムがマウントされ、kdump はコアをローカルに保存しようとします。この動作を変更する場合は root として、テキストエディターで /etc/kdump.conf 設定ファイルを開きます。#default shell の行頭にあるハッシュ記号 (#) を取り除き、表1.5「サポートしているデフォルトの動作」 の説明にしたがって値を目的の動作に変更します。
以下に例を示します。
default reboot
1.2.2.5. サービスの有効化
起動時に kdump デーモンを開始するには、シェルプロンプトで root として以下を入力します。
systemctlenablekdump.service
multi-user.target のサービスが有効になります。同様に systemctl stop kdump を入力するとこのサービスが無効になります。現在のセッションでサービスを開始する場合は root として、次のコマンドを使用します。
systemctlstartkdump.service
Red Hat Enterprise Linux 7 では kdump の出力先として指定されているディレクトリーが kdump systemd サービスの起動時に存在していなければなりません。起動時にこのディレクトリーが存在していないとサービスの起動は失敗します。この動作は Red Hat Enterprise Linux の以前のリリースと異なります。以前のリリースではサービスの起動時にこのディレクトリーが存在していないと自動的に作成されていました。
systemd およびサービスの設定全般については『Red Hat Enterprise Linux 7 システム管理者のガイド』を参照してください。
1.2.3. グラフィカルユーザーインターフェースでの kdump の設定
Kernel Dump Configuration ユーティリティーを起動するにはパネルから → → の順で選択するか、シェルプロンプトで system-config-kdump を入力します。図1.1「基本設定」 に示すウィンドウが表示されます。
このユーティリティーを使用すると kdump の設定のほか、起動時にサービスを有効または無効にすることもできます。設定が完了したら をクリックして変更を保存します。認証が済んでいる場合を除きスーパーユーザーのパスワード入力が求められます。また、設定の変更を適用するにはシステムの再起動が必要な旨を示すメッセージが表示されます。
SELinux が Enforcing モードで実行中の IBM System z または PowerPC システムでは、カーネルダンプ設定ユーティリティーを起動する前に kdumpgui_run_bootloader のブール値を有効化する必要があります。このブール値により、system-config-kdump が bootloader_t SELinux ドメインのブートローダーで実行できるようになります。このブール値を永続的に有効化するには、root として以下のコマンドを実行します。
# setsebool -P kdumpgui_run_bootloader 1
s390x ハードウェア上の DASD にダンプする場合には、続行する前に /etc/dasd.conf でダンプサービスが正しく指定されている必要があります。
1.2.3.1. メモリー使用量の設定
基本設定 タブでは kdump カーネル用に予約するメモリーサイズを設定できます。手動セッティング のラジオボタンを選択し、新規の kdump メモリー フィールドの横にある上矢印ボタンまたは下矢印ボタンをクリックして予約するメモリーサイズを増減させます。システムで使用できるメモリーの残量に応じて 使用可能なメモリー フィールドが変化します。kdump のメモリー要件については 「メモリーの要件」 を参照してください。
図1.1 基本設定

1.2.3.2. kdump タイプの設定
出力先 タブでは vmcore ダンプの出力先を指定することができます。ダンプはローカルのファイルシステムにファイルとして保存するか、デバイスに直接書き込むか、または NFS (Network File System) や SSH (Secure Shell) などのプロトコルを使ってネットワーク経由で送信することができます。
図1.2 出力先

ローカルのファイルシステムにダンプを保存する場合は ローカルファイルシステム のラジオボタンを選択します。必要に応じて パーティション のドロップダウンリストから別のパーティションを選択し、パス フィールドで出力先ディレクトリーを選択して設定をカスタマイズすることもできます。
Red Hat Enterprise Linux 7 では kdump の出力先として指定されているディレクトリーが kdump systemd サービスの起動時に存在していなければなりません。起動時にこのディレクトリーが存在していないとサービスの起動は失敗します。この動作は Red Hat Enterprise Linux の以前のリリースと異なります。以前のリリースではサービスの起動時にこのディレクトリーが存在していないと自動的に作成されていました。
デバイスに直接ダンプを書き込む場合は Raw デバイス ラジオボタンを選択し、目的の出力先デバイスをその横にあるドロップダウンリストから選択します。
ネットワーク接続経由で、リモートのマシンにダンプを送信する場合は ネットワーク ラジオボタンを選択します。NFS プロトコルを使用する場合は NFS ラジオボタンを選択して サーバー名 と ディレクトリーへのパス フィールドを入力します。SSH プロトコルを使用する場合は SSH ラジオボタンを選択して サーバー名、ディレクトリーへのパス、ユーザー名 のフィールドにリモートサーバーのアドレス、出力先ディレクトリー、有効なユーザー名をそれぞれ入力します。
SSH サーバーの設定方法およびキーベースの認証設定については『Red Hat Enterprise Linux 7 システム管理者のガイド』を参照してください。現在サポートしている出力先の一覧については 表1.3「サポートしている kdump のダンプ出力先」 を参照してください。
1.2.3.3. コアコレクターの設定
Filtering Settings (フィルタリングセッティング) タブでは、vmcore ダンプのフィルターレベルを選択することができます。
図1.3 フィルタリング

ダンプから ゼロページ、キャッシュページ、キャッシュプライベート、ユーザーデータ、または フリーページ を除外するには該当ラベルの横にあるチェックボックスを使って選択します。
1.2.3.4. デフォルト動作の設定
kdump がコアダンプの作成に失敗した場合に行う動作を選択するには、デフォルトの動作 のドロップダウンリストから適切なオプションを選択します。rootfs にダンプして再起動 (コアをローカルに保存してからシステムを再起動するデフォルトの動作)、再起動 (システムを再起動)、shell (対話式シェルプロンプトを表示)、停止 (システムを停止)、電源オフ (システムの電源を切断) などのオプションを選択することができます。
図1.4 フィルタリング

makedumpfile コアコレクターに渡されるオプションをカスタマイズするには コアコレクター のテキストフィールドを編集します。詳細は 「コアコレクターの設定」 を参照してください。
1.2.3.5. サービスの有効化
起動時に kdump サービスを開始する場合はツールバーの ボタンをクリックしてから ボタンをクリックします。これにより、multi-user.target のサービスが有効になり、起動します。 ボタンをクリックして ボタンをクリックするとサービスが直ちに無効になります。
Red Hat Enterprise Linux 7 では kdump の出力先として指定されているディレクトリーが kdump systemd サービスの起動時に存在していなければなりません。起動時にこのディレクトリーが存在していないとサービスの起動は失敗します。この動作は Red Hat Enterprise Linux の以前のリリースと異なります。以前のリリースではサービスの起動時にこのディレクトリーが存在していないと自動的に作成されていました。
systemd の出力先およびサービスの設定全般については『Red Hat Enterprise Linux 7 システム管理者のガイド』を参照してください。
1.3. kdump 設定のテスト
以下のコマンドを実行するとカーネルがクラッシュします。次の手順を行う場合は十分に注意してください。実稼働のシステムでは絶対に実行しないでください。
設定をテストするため kdump を有効にしてシステムを再起動し、サービスが実行されているか確認します。
~]# systemctl is-active kdump active
次に、シェルプロンプトで以下のコマンドを入力します。
echo 1 > /proc/sys/kernel/sysrqecho c > /proc/sysrq-trigger
このコマンドにより、Linux カーネルは強制的にクラッシュして address-YYYY-MM-DD-HH:MM:SS/vmcore ファイルが設定で選択した場所にコピーされます (デフォルトでは /var/crash/)。
このアクションは、設定の妥当性を確認するのに加え、典型的なテストロードで実行された場合にクラッシュダンプが完了するまでの所要時間を記録するために使用できます。
1.3.1. その他のリソース
1.3.1.1. インストールされているドキュメント
-
kdump.conf(5):
/etc/kdump.conf設定ファイルの man ページです。使用できるオプションの詳細な説明が参照できます。 -
zipl.conf(5):
/etc/zipl.conf設定ファイルの man ページです。 -
zipl(8): IBM System 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 のインストールと使用方法に関する概要です。
1.3.1.2. オンラインのドキュメント
- https://access.redhat.com/site/solutions/6038
-
kexecおよびkdump設定に関する Red Hat ナレッジベースアーティクルです。 - https://access.redhat.com/site/solutions/223773
-
サポートしている
kdump出力先に関する Red Hat ナレッジベースのアーティクルです。 - http://people.redhat.com/anderson/
- crash ユーティリティーのホームページです。
- https://www.gnu.org/software/grub/
- GRUB2 ブートローダーのホームページとドキュメントです。
1.4. ファームウェア支援ダンプの仕組み
1.4.1. ファームウェア支援ダンプについて
kexec および kdump の仕組みは、AMD64 および Intel 64 システムでコアダンプをキャプチャーする、信頼性が高く実績のある手法ですが、長い歴史を持つ一部のハードウェア (特に、ミニシステムおよびメインフレームシステム) では、オンボードのファームウェアを活用して、メモリーの領域を分離してクラッシュ解析に重要なデータが誤って上書きされるのを防ぐことができます。
本章では、利用可能なファームウェア支援ダンプの手法について紹介し、ファームウェア支援ダンプを Red Hat Enterprise Linux でどのように活用するかについて説明します。
1.4.2. IBM PowerPC ハードウェアにおける fadump の使用
ファームウェア支援ダンプ (fadump) は、IBM PowerPC LPARS で利用可能な kexec-kdump に代わる信頼性の高い仕組みです。ファームウェア支援ダンプでは、PCI および I/O デバイスが再初期化され、完全にリセットされたシステムから、vmcore がキャプチャーされます。この仕組みでは、クラッシュ発生時にファームウェアを使ってメモリーが保持されますが、kdump ユーザー空間スクリプトが再利用して vmcore を保存します。
そのために、fadump では、クラッシュ発生時にシステムファームウェアを使って保持する必要のあるメモリー領域が登録されます。これらの領域には、ブートメモリー、システムレジスター、およびハードウェアのページテーブルエントリー (PTE) を除く、すべてのシステムメモリーコンテンツが含まれます。
PowerPC 特有のハードウェアのリセット方法を含め、fadump の仕組みに関する詳細は、/usr/share/doc/kexec-tools-X.y.z/fadump-howto.txt を確認してください。ここで「X.y.z」は、お使いのシステムにインストールされている kexec-tools のバージョン番号を表します。
ブートメモリー と呼ばれる保持されないメモリー領域は、クラッシュ後にカーネルを正常に起動するのに必要な RAM の容量です。デフォルトのブートメモリーサイズは、256 MB または全システム RAM の 5% のいずれか大きい方です。
kexec で開始されたイベントとは異なり、fadump プロセスでは実稼働用のカーネルを使用してクラッシュダンプを復元します。クラッシュ後の起動時に、PowerPC ハードウェアはデバイスノード /proc/device-tree/rtas/ibm,kernel-dump が procfs で利用できるようにし、fadump 対応の kdump スクリプトは vmcore を保存するかどうかを確認します。この処理が完了すると、システムは正しく再起動されます。
fadump の有効化
-
「kdump のインストールと設定」 の記載通りに、
kdumpをインストールし、設定します。 /etc/default/grubのGRUB_CMDLINE_LINUXの行に、fadump=onを追加します。GRUB_CMDLINE_LINUX="rd.lvm.lv=rhel/swap crashkernel=auto rd.lvm.lv=rhel/root rhgb quiet
fadump=on"(この操作は必須ではありません) 予約ブートメモリーサイズにデフォルト値を使わずに具体的な値を指定する場合は、
GRUB_CMDLINE_LINUXin/etc/default/grubにfadump_reserve_mem=xxMを追加します。xx は必要なメモリーサイズ (メガバイト単位) に指定してください。GRUB_CMDLINE_LINUX="rd.lvm.lv=rhel/swap crashkernel=auto rd.lvm.lv=rhel/root rhgb quiet fadump=on
fadump_reserve_mem=xxM"
すべてのブート設定オプションと同様に、必要になる前に設定をテストすることを強く推奨します。クラッシュカーネルから起動時に Out of Memory (OOM) エラーが発生する場合は、クラッシュカーネルが正常に起動できるまで fadump_reserve_mem= で指定する値を増やします。この場合、試行錯誤が必要になることがあります。
1.4.3. IBM z Systems におけるファームウェア支援ダンプの手法
IBM z Systems には、Stand-alone Dump および VMDUMP の 2 つのファームウェア支援ダンプの仕組みがあります。
これらのシステムでは kdump インフラストラクチャーがサポートされ使用されています。Red Hat Enterprise Linux での設定は、「kdump のインストールと設定」 に説明がありますが、IBM z System ハードウェアが提供するこれらのファームウェア支援の手法を使用すると、いくつかのメリットが得られます。
スタンドアロンダンプ (SADMP) メカニズムはシステムコンソールから開始および制御され、IPL 起動可能デバイス上に保管される必要があります。
VMDUMP は SADMP と類似しています。このツールもシステムコンソールから開始されますが、得られるダンプをハードウェアからコピーし、解析のためにそれをシステムに格納する仕組みがあります。
(他のハードウェアベースのダンプメカニズムと同様に) これらの手法のメリットの 1 つは、(kdump サービスが開始される前の) 起動初期段階におけるマシンの状態をキャプチャーできるという点です。
VMDUMP には、ハードウェアからコピーしたダンプファイルを Red Hat Enterprise Linux システムに格納する仕組みがありますが、IBM z System ハードウェアコンソールから、SADMP および VMDUMP の両方の設定および制御が管理されます。
IBM では、これらの仕組みについて詳細な説明を用意しています。SADMP については http://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieav100/standa.htm を、VMDUMP については http://www.ibm.com/support/knowledgecenter/en/linuxonibm/com.ibm.linux.z.lgdt/lgdt_t_vmdump.html を、それぞれ参照してください。
IBM では、Red Hat Enterprise Linux 7 におけるダンプツールの使用についても文書化しています。http://www.ibm.com/support/knowledgecenter/linuxonibm/com.ibm.linux.z.lgdt/lgdt_t_usingdumptools.html を参照してください。
1.4.4. Fujitsu PRIMEQUEST システムにおける sadump の使用
Fujitsu の sadump メカニズムは、kdump が正常に完了できない場合にフォールバックダンプキャプチャーが実行されるように設計されています。
sadump プロセスは、システムの ManageMent Board (MMB) インターフェースから手動で呼び出します。
このシステムでは、通常通り kdump を X86_64 サーバーに対して設定し、さらに以下の追加ステップを実施して sadump を有効にする必要があります。
sadump に対して kdump が予想どおりに起動するように/etc/sysctl.conf で以下の行を追加または編集します。
kernel.panic=0 kernel.unknown_nmi_panic=1
上記の手順に加えて、/etc/kdump.conf にいくつかのオプションを追加して、sadump に対して kdump が正常に動作するようにする必要もあります。
特に、kdump の後にシステムが再起動しないようにする必要があります。kdump がコアの保存に失敗した後にシステムが再起動すると、sadump を呼び出す機会が失われます。
そのためには、/etc/kdump.conf の default アクションを halt または shell のどちらかに設定する必要があります。
default shell blacklist kvm-intel
sadump 用にハードウェアを設定する方法は、『FUJITSU Server PRIMEQUEST 2000 Series Installation Manual』を参照してください。
1.5. コアダンプの分析
システムクラッシュの原因を究明するには、GNU Debugger (GDB) と良く似た対話式のプロンプト crash ユーティリティーを使用することができます。稼働中の Linux システムだけでなく netdump、diskdump、xendump、kdump などで作成したコアダンプなども対話形式で分析することができます。
1.5.1. crash ユーティリティーのインストール
crash 分析ツールをインストールするには、root でシェルプロンプトから次のコマンドを実行します。
yum install crash
crash に加え、実行中のカーネルに対応する kernel-debuginfo パッケージもインストールしておく必要があります。このパッケージでダンプ分析に必要なデータが提供されます。kernel-debuginfo をインストールするには、root として debuginfo-install を使用します。
debuginfo-install kernelYum を使用した Red Hat Enterprise Linux の新規パッケージのインストール方法については『Red Hat Enterprise Linux 7 システム管理者のガイド』を参照してください。
1.5.2. crash ユーティリティーの実行
シェルプロンプトで次の形式のコマンドを入力してユーティリティーを起動します。
crash/usr/lib/debug/lib/modules/<kernel>/vmlinux\/var/crash/<timestamp>/vmcore
kdump によってキャプチャーされたものと同じ <kernel> のバージョンを使用してください。現在実行中のカーネルを確認するには、uname -r のコマンドを使用します。
例1.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>1.5.3. メッセージバッファーの表示
対話式プロンプトで log コマンドを入力して、カーネルメッセージバッファーを表示します。
例1.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/ ディレクトリーに配置されています。
1.5.4. バックトレースの表示
対話式プロンプトで bt コマンドを入力してカーネルのスタックトレースを表示します。1 プロセスのバックトレースを表示するには bt <pid> と入力します。
例1.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 と入力してください。
1.5.5. プロセスの状態表示
対話式プロンプトで ps コマンドを入力してシステム内のプロセスの状態を表示します。1 プロセスの状態を表示するには ps <pid> と入力します。
例1.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 と入力してください。
1.5.6. 仮想メモリー情報の表示
対話式プロンプトで vm コマンドを入力して仮想メモリーの基本情報を表示します。1 プロセスの情報を表示するには vm <pid> と入力します。
例1.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 と入力してください。
1.5.7. オープンファイルの表示
対話式プロンプトで files コマンドを入力してオープンファイルに関する情報を表示します。選択した 1 プロセスだけで開かれているファイルを表示するには files <pid> と入力します。
例1.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 と入力してください。
1.5.8. ユーティリティーの終了
対話式プロンプトを終了して、crash を終了するには、exit または q と入力します。
例1.7 crash ユーティリティーの終了
crash> exit ~]#
1.6. よくある質問
クラスター化された環境で kdump を使用する場合には、何に注意したら良いですか?
「RHEL 6 および 7 の High Availability アドオンで使用できるように kdump を設定する」の記事で、High Availability アドオンを使用しているシステム管理者が利用可能なオプションを説明しています。
起動初期に kdump が失敗します。どのようにしてブートログをキャプチャーするのですか?
2 番目のカーネルの起動に問題がある場合は、起動初期のブートログを確認する必要があります。問題のあるマシンに対するシリアルコンソールを有効にすることで、このログを取得することができます。
「Red Hat Enterprise Linux でシリアルターミナルやコンソールを設定する」の記事で、起動初期のブートメッセージへアクセスするために必要な設定が説明されています。
デバッグ用に、どのようにして makedumpfile からのメッセージを増やすのですか?
makedumpfile が失敗する時には、何が悪いのかを理解するためにログのレベルを増やさなければならない場合があります。これはダンプレベルを設定するのとは異なる操作です。ログのレベルについては、/etc/kdump.conf の core_collector 行の内容を編集して、makedumpfile に対する message_level オプションを増やします。
デフォルトでは makedumpfile はレベル 7 に設定されていて、進捗バー、共通メッセージ、およびエラーメッセージの出力が含まれます。このレベルを 31 に設定して、詳細なデバッグ情報を取得します。
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 には pvpanic と virsh dump という 2 つの仕組みがあります。これらの手法は 『仮想化の導入および管理ガイド』 に記載されています。
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、ヒープダンプ、ログファイルなど) を送付する 」を参照ください。
クラッシュダンプが完了するまでに、どれくらい時間がかかりますか?
災害対策計画を作成するためには、通常、ダンプ完了までの時間を把握している必要がありますが、所要時間は、ディスクにコピーされるメモリーの量や、メモリーとストレージのインターフェースのスピードに大きく左右されます。
テストがどのようなタイミングで行われても、システムは典型的な負荷をかけた状態で稼働させておく必要があります。そうでないと、除外されるページによって、完全に負荷がかかった実稼働システムにおける kdump の動作で誤った見解が提示される可能性があります。特にこの違いは、大量のメモリーが使用されている状況でより顕著に見られます。
ダンプの所要時間を評価する場合に、ストレージインターフェースもプランニング時に考慮する必要があります。ネットワーク制約事項が原因で、ローカルに接続された SATA ディスクと比べると、ssh などを使用した接続ダンプは完了までに長く時間がかかる可能性があります。
インストール時に Kdump をどのように設定するのですか?
キックスタートまたは対話型の GUI を使用すれば、わずかなオプションを指定するだけでインストール時に kdump を設定することができます。
anaconda インストール GUI を使用した kdump の設定については、『インストールガイド』の「Kdump」セクションに詳しい説明が記載されています。
kickstart 構文は以下の通りです。
%addon com_redhat_kdump [--disable,enable] [--reserve-mb=[auto,value]] %end
キックスタートに対するこのアドオンにより、kdump 機能の無効化/有効化や、オプションとして予約メモリーサイズの定義 (自動のデフォルトオプションを明示的に呼び出す、またはメガバイト単位で数値を指定する) が可能になります。なお、スイッチ全体が省略された場合も、デフォルトオプションが呼び出されます。
キックスタートを使用してシステムのデプロイメントを自動化する方法の詳細は、『インストールガイド』の「キックスタートを使ったインストール」を参照してください。
キックスタートアドオン構文の詳細については、『インストールガイド』の「キックスタート構文の参考資料」を参照してください。
1.7. サポートしている kdump の設定とダンプ出力先
1.7.1. kdump メモリー要件
kdump でカーネルクラッシュダンプをキャプチャーしてさらに分析ができるように保存するにはシステムメモリーの一部をキャプチャーカーネル用に永続的に予約する必要があります。以下の表には、システムのアーキテクチャーおよび利用可能な合計物理メモリーを基にした kdump の最小メモリー要件一覧が含まれます。
コマンドラインでメモリー設定を変更する方法については 「メモリー使用量の設定」 を参照してください。グラフィカルユーザーインターフェースで予約メモリーの設定を変更する方法については 「メモリー使用量の設定」 を参照してください。
表1.1 kdump 用に必要な最小予約メモリー
| アーキテクチャー | 使用可能なメモリー | 最小予約メモリー |
|---|---|---|
|
AMD64 および Intel 64 ( |
2 GB 以上 |
メモリー 4KB 毎に 160 MB + 2 ビット、メモリーが 1 TB のシステムの場合は、最低でも 224 MB 必要です (160 + 64 MB)。 |
|
IBM POWER ( |
2 GB から 4 GB |
256 MB のメモリー |
|
4 GB から 32 GB |
512 MB のメモリー | |
|
32 GB から 64 GB |
1 GB のメモリー | |
|
64 GB から 128 GB |
2 GB のメモリー | |
|
128 GB 以上 |
4 GB のメモリー | |
|
IBM System z ( |
2 GB 以上 |
メモリー 4KB 毎に 160 MB + 2 ビット、メモリーが 1 TB のシステムの場合は、最低でも 224 MB 必要です (160 + 64 MB)。 |
さまざまな Red Hat Enterprise Linux テクノロジーの機能や制限に関する詳しい情報は、https://access.redhat.com/articles/rhel-limits を参照してください。
1.7.2. メモリー自動予約の最小しきい値
一部のシステムでは、ブートローダーの設定ファイルで crashkernel=auto パラメーターを使用するか、グラフィカル設定ユーティリティーで自動割り当ての設定を有効にすると、kdump 用のメモリーを自動的に割り当てることができます。ただし、この自動予約が正常に機能するためには、特定のメモリー容量合計が利用できる状態でなければなりません。この容量はシステムのアーキテクチャーによって異なります。
以下の表で、自動メモリー割り当てのしきい値を一覧で表示します。システムのメモリーが以下に示すしきい値を下回る場合は手動でメモリー予約を行う必要があります。
コマンドラインで設定を変更する方法については 「メモリー使用量の設定」 を参照してください。グラフィカルユーザーインターフェースで予約メモリーのサイズを変更する方法については 「メモリー使用量の設定」 を参照してください。
表1.2 自動メモリー予約に必要な最小メモリーサイズ
| アーキテクチャー | 必要なメモリー |
|---|---|
|
AMD64 および Intel 64 ( |
2 GB |
|
IBM POWER ( |
2 GB |
|
IBM System z ( |
4 GB |
1.7.3. サポートしている kdump のダンプ出力先
カーネルクラッシュをキャプチャーする際、コアダンプを直接デバイスに書き込んでローカルファイルシステムにファイルとして保存するか、またはネットワーク経由で送信することができます。現在サポートしているダンプ出力先および kdump による非サポートが明確なダンプ出力先の全一覧を以下に示します。
コマンドラインでダンプ出力先を設定する方法については 「kdump タイプの設定」 を参照してください。グラフィカルユーザーインターフェースでダンプ出力先を設定する方法については 「kdump タイプの設定」 を参照してください。
表1.3 サポートしている kdump のダンプ出力先
| タイプ | サポートしているダンプ出力先 | 非サポートのダンプ出力先 |
|---|---|---|
|
Raw デバイス |
ローカルで添付されたすべての生デバイスとパーティション | |
|
ローカルファイルシステム |
直接アタッチされたディスクドライブ、ハードウェア RAID 論理ドライブ、LVM デバイス、 |
|
|
リモートディレクトリー |
|
|
|
ハードウェアおよびソフトウェアイニシエーター上で |
|
マルチパスベースのストレージ |
|
| ||
|
| ||
|
| ||
|
ワイヤレスネットワークインターフェースを使ってアクセスするリモートディレクトリー | ||
1.7.4. サポートしている kdump のフィルターレベル
ダンプファイルのサイズを縮小させるため kdump では makedumpfile コアコレクターを使ってデータを圧縮して必要に応じて関連性のない情報を除外します。以下の表では、現在、makedumpfile ユーティリティーでサポートしているフィルターのレベル全一覧を紹介します。
コマンドラインでコアコレクターを設定する方法については 「コアコレクターの設定」 を参照してください。グラフィカルインターフェースでコアコレクターを設定する方法については 「コアコレクターの設定」 を参照してください。
表1.4 サポートしているフィルターレベル
| オプション | 説明 |
|---|---|
|
|
ゼロページ |
|
|
キャッシュページ |
|
|
キャッシュプライベート |
|
|
ユーザーページ |
|
|
フリーページ |
makedumpfile コマンドは、Red Hat Enterprise Linux 7.3 以降の透過的なヒュージページおよび hugetlbfs ページの削除をサポートします。これらのタイプのヒュージページは、ユーザーページと見なされ、-8 レベルを使用して削除されます。
1.7.5. サポートしているデフォルトの動作
kdump がコアダンプの作成に失敗するとデフォルトでは root ファイルシステムをマウントしてコアのローカルへの保存を試行します。第 1 ダンプ出力先へのコアダンプの保存に失敗した場合、kdump に別の動作を行うよう設定することができます。kdump で現在サポートしているデフォルト動作を以下に示します。
コマンドラインでデフォルト動作を設定する方法については 「デフォルト動作の設定」 を参照してください。グラフィカルユーザーインターフェースでデフォルト動作を設定する方法については 「デフォルト動作の設定」 を参照してください。
表1.5 サポートしているデフォルトの動作
| オプション | 説明 |
|---|---|
|
|
コアダンプの root ファイルシステムへの保存を試行します。ネットワーク上のダンプ出力先と併用する場合に特に便利なオプションです。ネットワーク上のダンプ出力先にアクセスできない場合、ローカルにコアダンプを保存するよう kdump の設定を行います。ダンプ後システムは再起動されます。 |
|
|
システムを再起動します。コアダンプは失われます。 |
|
|
システムを停止します。コアダンプは失われます。 |
|
|
システムの電源を切ります。コアダンプは失われます。 |
|
|
initramfs 内から shell セッションを実行して、ユーザーが手動でコアダンプを記録できるようにします。 |
1.7.6. kdump サイズの予測
kdump 環境のプランニングや構築の際に、ダンプファイルに必要な容量がどれくらいか把握してから作成する必要があります。これには、makedumpfile コマンドを使用すると役立ちます。
--mem-usage オプションでは、除外可能なページに関する有用なレポートが提供され、これを使用して、割り当てるダンプレベルを判断することができます。このコマンドは、システムに典型的な負荷をかけた状態で実行する必要があります。そうでないと、makedumpfile は実稼動環境で必要とされる値よりも小さい値を返します。
[root@hostname ~]# makedumpfile --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 の場合は 4 キロバイトまたは 4096 バイト) に対して使用中のメモリーサイズを算出する必要があります。
1.8. kdump に関連する Portal Labs
Portal Labs は簡単な Web アプリケーションで、システム管理者がさまざまなシステムタスクを実施するのに役立ちます。kdump に関しては現在、Kdump Helper および Kernel Oops Analyzer の 2 つの Labs があります。
1.8.1. Kdump Helper
Kdump Helper は、一連の質問および操作で構成され、kdump 設定ファイルの準備を支援します。
Lab のワークフローには、クラスター化された環境およびスタンドアロン環境の両方に関する手順が含まれています。
1.8.2. Kernel Oops Analyzer
Kernel Oops Analyzer ツールを使うと、Oops メッセージを処理して、クラッシュダンプスタックを解析することなく既知のソリューションがあるかどうかを確認することができます。
Kernel Oops Analyzer では makedumpfile からの情報を使用し、クラッシュしたマシンの Oops メッセージとナレッジベースに蓄積された既知の問題を比較します。これにより、予期せぬ障害が発生しても、システム管理者はすばやく既知の問題の可能性を除外して、詳細な解析を依頼するためにサポートチケットを発行することができます。

Where did the comment section go?
Red Hat's documentation publication system recently went through an upgrade to enable speedier, more mobile-friendly content. We decided to re-evaluate our commenting platform to ensure that it meets your expectations and serves as an optimal feedback mechanism. During this redesign, we invite your input on providing feedback on Red Hat documentation via the discussion platform.