ハードウェアの障害、入出力の問題、ソフトウェアエラーなどが原因でシステムがクラッシュすることがあります。システムがクラッシュすると、システムはエラーメッセージをコンソールに表示し、物理メモリーのコピーをダンプデバイスに書き込みます。その後、システムは自動的にリブートします。システムがリブートするときに、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 Live Upgrade を使って UFS ルートファイルシステムから ZFS ルートファイルシステムに移行した場合は、ZFS ルートプールの ZFS ボリュームにスワップ領域が作成されます。スワップボリュームのサイズは物理メモリーのサイズの 1/2 (ただし 2G バイト以下かつ 512M バイト以上) として計算されます。ダンプボリュームのサイズは、dumpadm の情報と物理メモリーのサイズに基づいて、カーネルによって計算されます。JumpStart プロファイルで、または初期インストール時に、スワップボリュームとダンプボリュームのサイズを新しいサイズに調整することができます。ただし、システムの動作をサポートするサイズを選択する必要があります。詳細は、『Solaris ZFS 管理ガイド』の「スワップデバイスおよびダンプデバイスの ZFS サポート」を参照してください。
インストール後に ZFS スワップ領域やダンプ領域を変更する必要がある場合は、以前の リリース同様、swap または dumpadm コマンドを使用します。
ダンプデバイスの管理について、このマニュアルでは、「システムクラッシュダンプ情報の管理」を参照してください。
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 で保存したクラッシュダンプを購入先に送って、システムがクラッシュした原因を解析してもらうことも可能です。
Oracle Solaris OS でシステムクラッシュダンプ情報を管理するには、dumpadm コマンドを使用します。
オペレーティングシステムのクラッシュダンプを構成することもできます。dumpadm 構成パラメータでは、ダンプ内容、ダンプデバイス、クラッシュダンプファイルが保存されるディレクトリなどを指定します。
ダンプデータは、圧縮した形式でダンプデバイスに格納されます。カーネルのクラッシュダンプイメージは 4G バイトを超える場合があります。データを圧縮することにより、ダンプが速くなり、ダンプデバイスのディスク領域も少なくてすみます。
スワップ領域ではなく、専用のダンプデバイスがダンプ構成の一部にあると、クラッシュダンプファイルの保存はバックグラウンドで行われます。つまり、システムを起動する際、savecore コマンドが完了するのを待たなくても、次の段階に進むことができます。大容量のメモリーを搭載したシステムでは、savecore コマンドが完了する前にシステムが使用可能になります。
savecore コマンドで生成されるシステムクラッシュダンプファイルは、デフォルトで保存されます。
savecore -L コマンドは、動作中の Oracle Solaris OS でクラッシュダンプを取得できる新しい機能です。たとえば、パフォーマンスに問題が発生しているときやサービスが停止しているときなどにメモリーのスナップショットをとって、実行中のシステムの問題を解決するのに使用します。システムが実行中で、一部のコマンドがまだ使用できる場合は、savecore -L コマンドを使用してシステムのスナップショットをダンプデバイスに保存し、クラッシュダンプファイルをただちに savecore ディレクトリに書き込むことができます。システムが実行中であるため、専用のダンプデバイスを構成してある場合のみ、savecore -L コマンドを使用できます。
ダンプパラメータ |
説明 |
---|---|
ダンプデバイス |
システムがクラッシュしたときにダンプデータを一時的に保存するデバイス。ダンプデバイスがスワップ領域でない場合は、savecore がバックグラウンドで実行されるため、ブートプロセスの速度が上がる |
savecore ディレクトリ |
システムのクラッシュダンプファイルを保存するディレクトリ |
ダンプ内容 |
ダンプするメモリーデータの種類 |
最小空き容量 |
クラッシュダンプファイルを保存した後で savecore ディレクトリに必要な最小空き容量。空き容量を指定しないと、デフォルトで 1M バイトになる |
詳細は、dumpadm(1M) のマニュアルページを参照してください。
ダンプ構成パラメータは、dumpadm コマンドで管理します。
dumpadm コマンドは、システム起動時に svc:/system/dumpadm:default サービスによって呼び出されて、クラッシュダンプパラメータの構成を行います。
dumpadmコマンドは、/dev/dump インタフェースを通してダンプデバイスとダンプ内容を初期化します。
ダンプ構成が完了すると、savecore スクリプトは、クラッシュダンプファイルのディレクトリの場所を探します。次に、savecore を呼び出して、クラッシュダンプがあるかどうかを調べたり、クラッシュダンプディレクトリにある minfree ファイルの内容を確認したりします。
可用性とパフォーマンス上の理由のため、Solaris ボリュームマネージャーで管理されている専用ダンプデバイスを構成しないでください。スワップ領域を Solaris ボリュームマネージャーの管理下に置くことはできますが (この方法を推奨します)、ダンプデバイスは別に確保してください。