dumpadm - オペレーティングシステムクラッシュダンプの構成
/usr/sbin/dumpadm [-enpuy] [
-c content-type] [-d
dump-device]
[-m mink | minm |
min%] [-s savecore-dir]
[-r root-dir] [-z on | off]
dumpadm プログラムは、オペレーティングシステムクラッシュダンプ機能の構成を管理する管理コマンドです。クラッシュダンプは、致命的なシステムエラー時のコンピュータの物理メモリーのコピーです。重大なオペレーティングシステムエラーが発生すると、エラーを説明するメッセージがコンソールに出力されます。そのときオペレーティングシステムは、物理メモリーの内容を RAM 内に保持することによってクラッシュダンプを生成します。これが可能でない場合、物理メモリーの内容は定義済みダンプデバイス (通常はローカルディスクパーティション) に書き込まれます。all または allproc が指定されている場合は、ローカルディスクパーティションが必要です。
重大なオペレーティングシステムエラーは、オペレーティングシステム、関連付けられたデバイスドライバ、および読み込み可能モジュールのバグや、ハードウェアの故障によって発生する可能性があります。原因がどのようなものでも、クラッシュダンプ自体が、問題を診断するのに役立つ重要な情報をサポートエンジニアに提供します。このため、クラッシュダンプを収集してサポートプロバイダに提供することはとても重要です。オペレーティングシステムがクラッシュすると、ブート時に savecore(1M) ユーティリティーが自動的に実行されて、クラッシュダンプが取り出され、vmdump.X および vmdump-<secname>.X (X はダンプを識別する整数) というファイル名で、ファイルシステムに圧縮形式で書き込まれます。あとで、同じシステムまたは別のシステムで savecore(1M) を呼び出すことで、圧縮されたクラッシュダンプを vmcore.X および vmcore-<secname>.X という名前のファイルに展開できます。リブート時にクラッシュダンプを保存するディレクトリは、dumpadm コマンドを使用して構成できます。
デフォルトでは、スワップ領域とダンプ領域には専用の ZFS ボリュームが使用されます。ZFS でダンプ領域を設定する方法の詳細については、『ZFS 管理ガイド』を参照してください。
現在のダンプ構成を表示するには、引数なしの dumpadm コマンドを使用します。
example# dumpadm
Dump content: kernel pages with ZFS metadata
Dump device: /dev/zvol/dsk/rpool/dump (dedicated)
Savecore directory: /var/crash
Savecore enabled: yes
Save compressed: yes
オプションが指定されない場合、dumpadm は現在のクラッシュダンプ構成を表示します。上の例では一連のデフォルト値が表示されており、ダンプ内容はカーネルメモリーページと ZFS メタデータのみに設定されています。クラッシュダンプはメモリー内に保持され、必要に応じてダンプデバイスが使用されます。デフォルトでは、ダンプデバイスはルートプールの zvol です。savecore ファイルのディレクトリは /var/crash/ に設定されています。savecore がリブート時に自動的に実行され、圧縮形式でクラッシュダンプを保存するように設定されています。
1 つ以上のオプションが指定された場合、dumpadm は変更が有効であることを検証し、有効な場合はクラッシュダンプパラメータを再構成して結果の構成を表示します。ダンプパラメータを表示または変更するには、root である必要があります。
システムインストール時に dumpadm は、カーネルメモリーなどの内部情報に基づいて、ダンプファイルを格納するのに十分なサイズのダンプデバイスを確立します。その後、小さすぎてダンプファイルを格納できないダンプデバイスを作成しようとすると、dumpadm からエラーメッセージが発行されて処理が失敗します。
サポートしているオプションは、次のとおりです。
クラッシュダンプが指定されたダンプ内容で構成されるように、ダンプ構成を変更します。content-spec は、オプションの内容の種類と内容の修飾子で構成されています。
content-type は基本情報を提供し、内容の修飾子はダンプ対象の内容をさらに変更します。+ を使用すると、内容の修飾子によってダンプ対象のデータがさらに追加され、- を使用すると、そのデータが除外されます。
content-type は次のいずれかにできます。
カーネルメモリーページのみ。これにはカーネルページの基本セットのみが含まれ、内容の修飾子を使って指定できるページは含まれません。
すべてのメモリーページ。all を指定すると、システムイメージはダンプデバイスに書き込まれます。結果となるダンプにはファイルシステムバッファーのページが含まれます。
カーネルメモリーページ (「kernel」で指定されるもの) と、クラッシュダンプが起動された CPU 上でその時点で実行されていたスレッドを持つプロセスのメモリーページ。その CPU 上で実行中のスレッドが、どのユーザープロセスにも関連付けられていないカーネルスレッドである場合、カーネルページのみがダンプされます。
カーネルメモリーページ (「kernel」で指定されるもの) とすべてのプロセスページ。allproc を指定すると、システムイメージはダンプデバイスに書き込まれます。
content-modifier は次のいずれかにできます。
ZFS メタデータを格納するカーネルページ。
content-modifier は、カーネルメモリーのどの部分がダンプされ、どの部分がダンプされないかに影響を及ぼします。それらは、内容の種類を「all」に設定している場合にはまったく効果がありません。
content-type が指定されていない場合は、現在構成されている内容の種類が変更されます。
指定されたダンプデバイスを使用するようにダンプ構成を変更します。ダンプデバイスは次のいずれかを指定できます。
/dev/dsk/cNtNdNsN のように絶対パス名で指定された特定のダンプデバイス、または /dev/zvol/dsk/rpool/dump などの ZFS ボリューム。
ダンプデバイスとして特殊トークン swap を指定した場合、dumpadm はアクティブスワップエントリを調べ、ダンプデバイスとして構成するのにもっとも適したエントリを選択します。swap(1M) を参照してください。適切なスワップエントリの選択に使用されるアルゴリズムの詳細については、後述の「注意事項」を参照してください。
特定の ZFS ボリュームをスワップ領域かつダンプデバイスとして構成することはできません。
圧縮されたクラッシュダンプの格納に必要なディスク容量の概算を出力します。この値は、現在の構成および現在実行中のシステムを使用して算出されます。
minfree ファイル (savecore ディレクトリがあるファイルシステム内で指定された量以上の空き領域を savecore が維持すべきであることを示す) を現在の savecore ディレクトリ内に作成します。min 引数は次のいずれかを指定できます。
K バイトを表す単位 k が末尾に付いた正の整数。
M バイトを表す単位 m が末尾に付いた正の整数。
minfree 値を、savecore ディレクトリを含むファイルシステムの現在の合計サイズの指定されたパーセント値として計算すべきであることを示す、% 記号。
savecore コマンドは、minfree ファイルがある場合、ダンプファイルに書き込む前に参照します。これらのファイルのサイズによって空きディスク容量が minfree しきい値より下回る場合、ダンプファイルは書き込まれず、エラーメッセージが記録されます。管理者は十分な空き容量を確保するためにすぐに savecore ディレクトリをクリーンアップし、savecore コマンドを手動で再度実行すべきです。管理者は、savecore コマンド行で代替ディレクトリを指定することもできます。
リブート時に savecore が自動的に実行されないようにダンプ構成を変更します。これは推奨されるシステム構成ではありません。システムはクラッシュダンプイメージをメモリー内に保持しようとします。dumpadm –n が設定されている場合は、システムのリブート後にクラッシュダンプイメージがダンプデバイスに書き込まれます。システムがブートしたあとで savecore (1M) を実行すると、クラッシュダンプを savecore ディレクトリに抽出できます。
ダンプデバイスがスワップパーティションの場合、システムがスワップを開始するとダンプデータが上書きされます。ブート直後に savecore が実行されない場合は、クラッシュダンプを収集できない場合があります。
マシン解析可能な出力を生成します。
dumpadm がファイルを作成する際の起点となる代替ルートディレクトリを指定します。–r 引数を指定しない場合は、デフォルトルートディレクトリ / が使用されます。
savecore によって書き込まれるファイルを保存するために、指定したディレクトリを使用するようにダンプ構成を変更します。このディレクトリは絶対パスで、システム上に存在しているべきです。リブート時にディレクトリが存在しない場合は、savecore の実行前に作成されます。savecore ディレクトリへのアクセスに関連するセキュリティ問題については、後述の「注意事項」セクションを参照してください。デフォルト savecore ディレクトリは、/var/crash/ です。
カーネルダンプ構成を /etc/dumpadm.conf の内容に基づいて強制的に更新します。このオプションは通常、リブート時に svc:/system/dumpadm:default を起動するときに、以前のブートからの dumpadm 設定を復元する必要があるときにのみ使用されます。ダンプ構成はこの目的のために構成ファイルに保存されます。構成ファイルがないかいずれかのダンププロパティーに無効な値を含んでいる場合は、デフォルト値で置き換えられます。更新後、構成ファイルはカーネルダンプ構成と再同期されます。
リブート時に savecore を自動的に実行するように、ダンプ構成を変更します。これはこのダンプ設定のデフォルトです。「注意事項」を参照してください。
リブート時の savecore の動作を制御するように、ダンプ構成を変更します。オプションは、コアファイルを圧縮形式で保存することを有効にする on と、クラッシュダンプファイルを自動的に圧縮解除する off です。デフォルトは on で、理由はクラッシュダンプファイルは非常に大きくなる可能性があり、圧縮形式で保存すれば必要なファイルシステム容量が少なくなるためです。
example# dumpadm -c curproc-zfs
Dump content: kernel and current process pages without ZFS metadata
Dump device: /dev/zvol/dsk/rpool/dump (dedicated)
Savecore directory: /var/crash
Savecore enabled: yes
Save compressed: on
使用例 2 allproc または all の内容を指定する
allproc または all の内容が指定された場合、クラッシュダンプをメモリー内に保持する試みは行われません。
example# dumpadm -c all
Dump content: all
Dump device: /dev/zvol/dsk/rpool/dump (dedicated)
Savecore directory: /var/crash
Savecore enabled: yes
Save compressed: on
使用例 3 savecore が無効な場合にクラッシュダンプを保持する
savecore が無効になっている場合、クラッシュダンプはメモリー内に保持され、ダンプデバイスにコピーされます。あとで savecore (1M) を手動で実行して抽出できます。
example# dumpadm -n -c kernel+zfs
Dump content: kernel with ZFS metadata
Dump device: /dev/zvol/dsk/rpool/dump (dedicated)
Savecore directory: /var/crash
Savecore enabled: yes
Save compressed: on
次の終了ステータスが返されます。
ダンプ構成が有効で、指定された変更 (ある場合) が正常に行われた。
ダンプ構成を取得または変更するときに致命的エラーが発生した。
無効なコマンド行オプションが指定された。
ダンプデバイス。
dumpadm の構成パラメータを含みます。このコマンドでのみ変更できます。
savecore-directory の最小空き容量を含みます。savecore(1M) を参照してください。
属性についての詳細は、マニュアルページの attributes(5) を参照してください。
|
svcs(1)、uname(1)、savecore(1M)、svcadm(1M)、swap(1M)、attributes(5)、smf(5)
システムクラッシュダンプサービスは、サービス管理機能 smf(5) によって、次のサービス識別子の下で管理されます。
svc:/system/dumpadm:default
有効化、無効化、または再起動要求など、このサービスに関する管理操作は、svcadm(1M) を使用して実行できます。サービスステータスを照会するには、svcs(1) コマンドを使用します。
dumpadm –d の引数として特殊な swap トークンが指定されると、ユーティリティーはもっとも適したスワップデバイスをダンプデバイスとして構成しようとします。dumpadm はもっとも大きなスワップブロック型デバイスをダンプデバイスとして構成します。スワップに使用できるブロック型デバイスがない場合は、もっとも大きなスワップエントリがダンプデバイスとして構成されます。スワップエントリが存在しないか、ダンプデバイスとして構成できるものがない場合は、警告メッセージが表示されます。ローカルおよびリモートスワップファイルをダンプデバイスとして構成できますが、これは推奨されていません。
ダンプデバイスがスワップデバイスでもある場合に、スワップデバイスが管理者によって swap –d コマンドを使って削除されると、swap コマンドは別の適切なスワップデバイスをダンプデバイスとして構成しようとして dumpadm –d swap を自動的に呼び出します。スワップデバイスが残っていないかダンプデバイスとして構成できるものがない場合には、クラッシュダンプが無効になり、警告メッセージが表示されます。同様に、クラッシュダンプが無効なときに管理者が swap –a コマンドを使って新しいスワップデバイスを追加すると、新しいスワップデバイスを使ってクラッシュダンプを再度有効にするために dumpadm –d swap が呼び出されます。
dumpadm –d swap が発行されると、それ以降のリブートのために新しいダンプデバイスが構成ファイル内に格納されます。管理者によってより大きなまたはより適したスワップデバイスが追加されても、ダンプデバイスは変更されません。管理者は、dumpadm –d swap を再実行して最適なデバイスをスワップデバイスの新しいリストから再選択する必要があります。
dumpadm –m オプションを使って savecore ディレクトリを含むファイルシステムの合計サイズのパーセント値に基づいて minfree ファイルが作成された場合、その後ファイルシステムのサイズが変更されても、この値は自動的に再計算されません。この場合、管理者が dumpadm –m を再実行して minfree 値を再計算する必要があります。savecore ディレクトリ内にそのようなファイルが存在しない場合、savecore はデフォルトで空き容量しきい値として 1M バイトを使用します。空き容量しきい値が不要な場合は、サイズ 0 を含む minfree ファイルを作成できます。
ダンプディレクトリの容量が十分でなく、クラッシュダンプイメージがメモリー内に保持されている場合、イメージはダンプデバイスに書き込まれ、あとで savecore (1M) を使用して抽出できます。
リブート時に、指定された savecore ディレクトリが存在しない場合、savecore を実行する前に、アクセス権 0700 (所有者のみによる読み取り、書き込み、実行)、所有者 root で作成されます。オペレーティングシステムクラッシュダンプファイル自体にセキュア情報が含まれている可能性があるため、同様のアクセス権で代替 savecore ディレクトリを作成することもお勧めします。
システムインストールソフトウェアが専用ダンプデバイス (ディスクスライスや ZFS ボリュームなど) を予約する場合があります。そのような場合、dumpadm のデフォルトを、システムリブート時に savecore が自動的に実行されないことを意味する –n に設定してもかまいません。クラッシュイメージは、最初はメモリー内に保持された場合でも、ダンプデバイス上に保持されます。root として /usr/bin/savecore を手動で実行してクラッシュイメージを取り出し、それを /var/crash の下の一連のファイルにコピーします。クラッシュイメージは、後続のもので上書きされるまでダンプデバイス上に残ります。