test

Solaris のシステム管理 (上級編)

システムクラッシュ (概要)

ハードウェアの障害、入出力の問題、ソフトウェアエラーなどが原因でシステムがクラッシュすることがあります。システムがクラッシュすると、システムはエラーメッセージをコンソールに表示し、物理メモリーのコピーをダンプデバイスに書き込みます。その後、システムは自動的にリブートします。システムがリブートするときに、savecore コマンドが実行されてダンプデバイスからデータが取り出され、保存されたクラッシュダンプが savecore ディレクトリに書き込まれます。保存されたクラッシュダンプファイルは、問題の診断に役立つ非常に重要な情報をサポート担当者に提供します。

クラッシュダンプ情報は圧縮した形式で vmdump. n ファイルに書き込まれます。この n は、クラッシュダンプ識別用の整数です。その後、同じシステムまたは別のシステムで savecore コマンドを呼び出して、圧縮されているクラッシュダンプを、unix. n および vmcore.n という名前の 1 組のファイルに展開できます。リブート時にクラッシュダンプが保存されるディレクトリも、dumpadm コマンドを使用して構成できます。

UFS ルートファイルシステムがあるシステムの場合、デフォルトのダンプデバイスは適切なスワップパーティションとして構成されます。スワップパーティションは、オペレーティングシステム用の仮想メモリーのバックアップストレージとして予約されているディスクパーティションです。このため、クラッシュダンプによって上書きされることになるスワップ内に、永続的な情報は置かれません。Oracle Solaris ZFS ルートファイルシステムがあるシステムの場合、スワップとダンプの領域用には専用の ZFS ボリュームが使用されます。詳細については、「スワップ領域およびダンプデバイスに関する Oracle Solaris ZFS サポート」を参照してください。

スワップ領域およびダンプデバイスに関する Oracle Solaris ZFS サポート

ソフトウェアの初期インストール時に Oracle Solaris ZFS ルートファイルシステムを選択した場合、または Oracle Solaris Live Upgrade を使って UFS ルートファイルシステムから ZFS ルートファイルシステムに移行した場合は、ZFS ルートプールの ZFS ボリュームにスワップ領域が作成されます。スワップボリュームのサイズは物理メモリーのサイズの 1/2 (ただし 2G バイト以下かつ 512M バイト以上) として計算されます。ダンプボリュームのサイズは、dumpadm の情報と物理メモリーのサイズに基づいて、カーネルによって計算されます。JumpStart プロファイルで、または初期インストール時に、スワップボリュームとダンプボリュームのサイズを新しいサイズに調整することができます。ただし、システムの動作をサポートするサイズを選択する必要があります。詳細は、『Solaris ZFS 管理ガイド』の「スワップデバイスおよびダンプデバイスの ZFS サポート」を参照してください。

インストール後に ZFS スワップ領域やダンプ領域を変更する必要がある場合は、以前の リリース同様、swap または dumpadm コマンドを使用します。

ダンプデバイスの管理について、このマニュアルでは、「システムクラッシュダンプ情報の管理」を参照してください。

x86: GRUB ブート環境のシステムクラッシュ

GRUB ブート環境の x86 システムでシステムクラッシュが発生した場合、GRUB ブートアーカイブ (svc:/system/boot-archive:default) を管理する SMF サービスが、次のシステムリブート時に失敗する可能性があります。GRUB ベースのブートの詳細については、『Solaris のシステム管理 (基本編)』の「GRUB を使用して x86 システムをブートする (作業マップ)」を参照してください。

システムクラッシュダンプファイル

システムクラッシュの後で自動的に実行される savecore コマンドは、ダンプデバイスからクラッシュダンプ情報を取り出し、unix.X と vmcore.X という 1 対のファイルを作成します。X はダンプの通し番号です。これらのファイルは 2 つで、保存されたシステムクラッシュダンプの情報を表します。

クラッシュダンプファイルはコアファイルと混同されることがあります。コアファイルは、アプリケーションが異常終了したときに書き込まれるユーザーアプリケーションのイメージです。

クラッシュダンプファイルは、あらかじめ決められたディレクトリに保存されます。これはデフォルトでは /var/crash/hostname です。以前の リリースでは、システムを手動で有効にして物理メモリーのイメージをクラッシュダンプファイルに保存しない限り、システムがリブートされた時にクラッシュダンプファイルが上書きされていました。このリリースでは、クラッシュダンプファイルの保存がデフォルトで有効です。

システムクラッシュ情報は dumpadm コマンドで管理します。詳しくは、「dumpadm コマンド」を参照してください。

クラッシュダンプの保存

制御構造体、アクティブなテーブル、動作中またはクラッシュしたシステムカーネルのメモリーのイメージなど、カーネルの動作状況についての情報を調べるには、mdb ユーティリティーを使用します。mdb を完全に使いこなすには、カーネルについての詳細な知識が必要ですが、このマニュアルでは説明を省きます。このユーティリティーの使用法については、mdb(1) のマニュアルページを参照してください。

さらに、savecore で保存したクラッシュダンプを購入先に送って、システムがクラッシュした原因を解析してもらうことも可能です。

dumpadm コマンド

Oracle Solaris OS でシステムクラッシュダンプ情報を管理するには、dumpadm コマンドを使用します。

次の表で、 dumpadm 構成パラメータを説明します。

ダンプパラメータ 

説明 

ダンプデバイス 

システムがクラッシュしたときにダンプデータを一時的に保存するデバイス。ダンプデバイスがスワップ領域でない場合は、savecore がバックグラウンドで実行されるため、ブートプロセスの速度が上がる

savecore ディレクトリ

システムのクラッシュダンプファイルを保存するディレクトリ 

ダンプ内容 

ダンプするメモリーデータの種類  

最小空き容量 

クラッシュダンプファイルを保存した後で savecore ディレクトリに必要な最小空き容量。空き容量を指定しないと、デフォルトで 1M バイトになる

詳細は、dumpadm(1M) のマニュアルページを参照してください。

ダンプ構成パラメータは、dumpadm コマンドで管理します。

dumpadm コマンドの動作

dumpadm コマンドは、システム起動時に svc:/system/dumpadm:default サービスによって呼び出されて、クラッシュダンプパラメータの構成を行います。

dumpadmコマンドは、/dev/dump インタフェースを通してダンプデバイスとダンプ内容を初期化します。

ダンプ構成が完了すると、savecore スクリプトは、クラッシュダンプファイルのディレクトリの場所を探します。次に、savecore を呼び出して、クラッシュダンプがあるかどうかを調べたり、クラッシュダンプディレクトリにある minfree ファイルの内容を確認したりします。

ダンプデバイスとボリュームマネージャー

可用性とパフォーマンス上の理由のため、Solaris ボリュームマネージャーで管理されている専用ダンプデバイスを構成しないでください。スワップ領域を Solaris ボリュームマネージャーの管理下に置くことはできますが (この方法を推奨します)、ダンプデバイスは別に確保してください。