Show Table of Contents
26.2.3. コマンドライン上で kdump の設定
26.2.3.1. メモリー使用量の設定
kdump カーネル用に確保するメモリ容量を設定するには、root としてテキストエディターで /boot/grub/grub.conf ファイルを開き、例26.1「サンプルの /boot/grub/grub.conf ファイル」 に示したように、カーネルオプションのリストに crashkernel=<size>M (または、crashkernel=auto) パラメーターを追加します。
重要
システムに十分なメモリーがなければ、
kdump クラッシュリカバリーサービスは動作しません。最小のメモリー要件については、『Red Hat Enterprise Linux Technology capabilities and limits』 comparison chart (バージョン比較) の 『Required minimums (最小メモリ容量)』 のセクションを参照して下さい。kdump クラッシュリカバリが有効化されている場合、最小のメモリー要件は、クラッシュリカバリに確保されているメモリー容量の分が増えます。この値はユーザーによって決定され、crashkernel=auto オプションが使用されていると、デフォルトでは 128 MB に物理メモリー 1 TB ごとに 64 MB を加えたものとなります (つまり、物理メモリーが 1 TB のシステムでは、合計 192 MB になります) 。
重要
Red Hat Enterprise Linux 6 では、
crashkernel=auto オプションは、システムに 4 GB 以上の物理メモリーがある場合のみ、メモリーを確保します。
例26.1 サンプルの /boot/grub/grub.conf ファイル
# grub.conf generated by anaconda
#
# Note that you do not have to rerun grub after making changes to this file
# NOTICE: You have a /boot partition. This means that
# all kernel and initrd paths are relative to /boot/, eg.
# root (hd0,0)
# kernel /vmlinuz-version ro root=/dev/sda3
# initrd /initrd
#boot=/dev/sda
default=0
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
title Red Hat Enterprise Linux Server (2.6.32-220.el6.x86_64)
root (hd0,0)
kernel /vmlinuz-2.6.32-220.el6.x86_64 ro root=/dev/sda3 crashkernel=128M
initrd /initramfs-2.6.32-220.el6.x86_64.img26.2.3.2. ターゲットタイプの設定
カーネルクラッシュがキャプチャーされる場合、コアダンプは、ローカルファイルシステムにファイルとして格納されるか、デバイスに直接書き込まれるか、NFS (Network File System) または SSH (Secure Shell) のプロトコルを使用したネットワーク上で送信されるか、のいずれかの方法で処理が可能です。現時点で設定できるのは、これらのオプションのうちの一つのみである点に注意して下さい。デフォルトのオプションは、
vmcore ファイルをローカルファイルシステムの /var/crash/ ディレクトリ内に格納する方法です。このオプションを変更するには、root としてテキストエディターで /etc/kdump.conf 設定ファイルを開き、以下のようにオプションを編集します。
コアダンプを保存するローカルディレクトリを変更するには、
#path /var/crash の行頭のハッシュサイン (「#」) を削除し、値を任意のディレクトリのパスに置き換えます。オプションとして、ファイルを異なるパーティションに書き込むには、#ext4 /dev/sda3 の行についても、同じ手順に従って、ファイルシステムタイプとデバイス (デバイス名、ファイルシステムラベル、UUID をすべてサポート) を適宜変更します。以下が例となります:
ext3 /dev/sda4 path /usr/local/cores
デバイスに直接ダンプディレクトリを書き込むには、
#raw /dev/sda5 の行頭のハッシュサイン (「#」) を削除して、値を任意のデバイス名に置き換えます。以下が例となります:
raw /dev/sdb1
NFS プロトコルを使用してリモートのマシンにダンプを保存するには、
#net my.server.com:/export/tmp の行頭からハッシュサイン (「#」) を削除して、値を有効なホスト名とディレクトリパスに置き換えます。以下が例となります:
net penguin.example.com:/export/cores
SSH プロトコルを使用してリモートのマシンにダンプを格納するには、
#net user@my.server.com の行頭のハッシュサイン (「#」) を削除し、値を有効なユーザー名とホスト名に置き換えます。以下が例となります:
net john@penguin.example.com
SSH サーバーの設定方法及びキーベース認証の設定方法については、12章OpenSSH を参照して下さい。
現在サポートされているターゲットの完全な一覧は、表26.1「サポートされている kdump ターゲット」 を参照して下さい。
26.2.3.3. コアコレクターの設定
kdump では、vmcore ダンプファイルのサイズを縮小する目的で、外部アプリケーション (コアコレクター) を指定してデータを圧縮することができます。又、オプションとして関連性のない情報をすべて除外することも可能です。現在、完全にサポートされている唯一のコアコレクターは makedumpfile です。
コアコレクターを有効にするには、
root としてテキストエディターで /etc/kdump.conf 設定ファイルを開き、#core_collector makedumpfile -c --message-level 1 -d 31 行の先頭にあるハッシュサイン (「#」) を削除してから、以下のようにコマンドラインオプションを編集します。
ダンプファイルの圧縮を有効にするには、
-c パラメーターを追加します。以下が例となります:
core_collector makedumpfile -c
ダンプから特定のページを削除するには、
-d value パラメーターを追加します。ここで value は、表26.2「サポートされているフィルターレベル」 に記載したページの値の合計です。例えば、ゼロとフリーページの両方を削除するには、以下を使用します。
core_collector makedumpfile -d 17 -c
使用可能なオプションの完全な一覧は、
makedumpfile の man ページを参照して下さい。
表26.2 サポートされているフィルターレベル
| オプション | 詳細 |
|---|---|
1 | ゼロページ |
2 | キャッシュページ |
4 | キャッシュプライベート |
8 | ユーザーページ |
16 | フリーページ |
26.2.3.4. デフォルトの動作の変更
デフォルトでは、
kdump がコアダンプの作成に失敗すると、ルートのファイルシステムがマウントされ、/sbin/init が実行されます。この動作を変更するには、root としてテキストエディターで /etc/kdump.conf 設定ファイルを開き、#default shell の行頭のハッシュサイン (「#」) を削除してから、値を 表26.3「サポートされている動作」 に記載した任意の動作に置き換えます。
表26.3 サポートされている動作
| オプション | 詳細 |
|---|---|
reboot | システムを再起動します。その過程でコアは失われます。 |
halt | システムを停止します。 |
poweroff | システムの電源を切断します。 |
shell | initramfs 内で msh セッションを実行し、ユーザーがコアを手動で記録できるようにします。 |
例:
default halt
26.2.3.5. サービスの有効化
ブート時に
kdump デーモンを起動するには、シェルプロンプトで root として以下を入力します。
chkconfigkdumpon
これにより、ランレベル
2、3、4、5 に対してサービスが有効になります。同様に、chkconfig kdump off と入力すると、すべてのランレベルに対してサービスが無効となります。現行セッションでサービスを起動するには、root として以下のコマンドを使用します。
servicekdumpstart
ランレベルとサービス設定全般に関する詳細は 10章サービスとデーモン を参照して下さい。

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.