第 17 章 システムクラッシュ情報の管理 (手順)

この章では、Solaris オペレーティングシステムでシステムクラッシュ情報を管理する方法を説明します。

システムクラッシュ情報の管理に関連する手順については、「システムクラッシュ情報の管理 (作業マップ)」を参照してください。

システムクラッシュ情報の管理 (作業マップ)

次の作業マップは、システムクラッシュ情報の管理に必要な手順を示します。

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

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

スワップ領域およびダンプデバイスの ZFS サポート

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

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

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

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

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

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

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

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

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

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

クラッシュダンプの保存

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

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

dumpadm コマンド

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

• オペレーティングシステムのクラッシュダンプを構成することもできます。dumpadm 構成パラメータでは、ダンプ内容、ダンプデバイス、クラッシュダンプファイルが保存されるディレクトリなどを指定します。

• ダンプデータは、圧縮した形式でダンプデバイスに格納されます。カーネルのクラッシュダンプイメージは 4G バイトを超える場合があります。データを圧縮することにより、ダンプが速くなり、ダンプデバイスのディスク領域も少なくてすみます。

• スワップ領域ではなく、専用のダンプデバイスがダンプ構成の一部にあると、クラッシュダンプファイルの保存はバックグラウンドで行われます。つまり、システムを起動する際、savecore コマンドが完了するのを待たなくても、次の段階に進むことができます。大容量のメモリーを搭載したシステムでは、savecore コマンドが完了する前にシステムが使用可能になります。

• savecore コマンドで生成されるシステムクラッシュダンプファイルは、デフォルトで保存されます。

• savecore -L コマンドは、動作中の Solaris OS でクラッシュダンプを取得できる新しい機能です。たとえば、パフォーマンスに問題が発生しているときやサービスが停止しているときなどにメモリーのスナップショットをとって、実行中のシステムの問題を解決するのに使用します。システムが実行中で、一部のコマンドがまだ使用できる場合は、savecore -L コマンドを使用してシステムのスナップショットをダンプデバイスに保存し、クラッシュダンプファイルをただちに savecore ディレクトリに書き込むことができます。システムが実行中であるため、専用のダンプデバイスを構成してある場合のみ、savecore -L コマンドを使用できます。

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

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

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

dumpadm コマンドの動作

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

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

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

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

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

システムクラッシュダンプ情報の管理

システムクラッシュ情報を処理する場合には、次の点に注意してください。

• システムクラッシュ情報にアクセスして管理するには、スーパーユーザーでログインするか、同等の役割になる必要があります。

• システムクラッシュダンプを保存するオプションを無効にしないでください。システムクラッシュファイルにより、システムクラッシュの原因を判断する非常に有効な方法が提供されます。

• また、重要なシステムクラッシュ情報は、カスタマサービス担当者に送信するまでは削除しないでください。

現在のクラッシュダンプ構成を表示する方法

1. スーパーユーザーになるか、同等の役割を引き受けます。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

2. 現在のクラッシュダンプ構成を表示します。

   # dumpadm Dump content: kernel pages Dump device: /dev/dsk/c0t3d0s1 (swap) Savecore directory: /var/crash/venus Savecore enabled: yes

   上記の出力例の意味は次のとおりです。

   • ダンプの内容は、カーネルメモリーページである

   • カーネルメモリーがスワップデバイス /dev/dsk/c0t3d0s1 にダンプされる。swap -l コマンドにより、すべてのスワップ領域を識別できる

   • システムクラッシュダンプファイルは /var/crash/venus ディレクトリに保存される

   • システムクラッシュダンプファイルの保存は有効に設定されている

クラッシュダンプ構成を変更する方法

1. スーパーユーザーになるか、同等の役割を引き受けます。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

2. 現在のクラッシュダンプ構成を確認します。

   # dumpadm Dump content: kernel pages Dump device: /dev/dsk/c0t3d0s1 (swap) Savecore directory: /var/crash/pluto Savecore enabled: yes

   この出力は、Solaris 10 リリースを実行するシステムのデフォルトダンプ構成を表しています。

3. クラッシュダンプ構成を変更します。

   # dumpadm -c content -d dump-device -m nnnk | nnnm | nnn% -n -s savecore-dir

   -c content

   ダンプするデータの種類を指定する。すべてのカーネルメモリーをダンプするには kernel を、すべてのメモリーをダンプするには all を、カーネルメモリーとクラッシュ時に実行中だったスレッドを持つプロセスのメモリーページとをダンプするには curproc を使用する。デフォルトはカーネルメモリー

   -d dump-device

   システムがクラッシュしたときに、ダンプデータを一時的に保存するデバイスを指定する。デフォルトのダンプデバイスは 1 次スワップデバイス

   -m nnnk | nnnm | nnn%

   現在の savecore ディレクトリに minfree ファイルを作成することにより、クラッシュダンプファイルを保存する最小限の空き容量を指定する。このパラメータは K バイト (nnnk)、M バイト (nnnm)、またはファイルシステムサイズのパーセント (nnn%) で指定できる。savecore コマンドは、クラッシュダンプファイルを書き込む前にこのファイルを調べる。クラッシュダンプファイルを書き込むと空き容量が minfree の値より少なくなる場合、ダンプファイルは書き込まれず、エラーメッセージが記録される。このような問題を解決するには、「クラッシュダンプディレクトリが一杯になった場合に復元する方法 (省略可能)」を参照してください。

   -n

   システムがリブートするときに、savecore を実行しないように指定する。このダンプ構成は推奨できない。システムクラッシュ情報がスワップデバイスに書き込まれているときに、savecore が有効でないと、クラッシュダンプ情報はシステムがスワップを開始すると上書きされる

   -s

   クラッシュダンプファイルを保存する別のディレクトリを指定する。デフォルトのディレクトリは /var/crash/hostname で、hostname は uname -n コマンドの出力

例 17–1 クラッシュダンプ構成を変更する

次の例は、すべてのメモリーを専用のダンプデバイス /dev/dsk/c0t1d0s1 にダンプします。また、クラッシュダンプファイルを保存した後に残っていなければならない最小空き容量は、ファイルシステム容量の 10% です。

# dumpadm
      Dump content: kernel pages
       Dump device: /dev/dsk/c0t3d0s1 (swap)
Savecore directory: /var/crash/pluto
  Savecore enabled: yes
 # dumpadm -c all -d /dev/dsk/c0t1d0s1 -m 10%
      Dump content: all pages
       Dump device: /dev/dsk/c0t1d0s1 (dedicated)
Savecore directory: /var/crash/pluto (minfree = 77071KB)
  Savecore enabled: yes

クラッシュダンプを検査する方法

1. スーパーユーザーになるか、同等の役割を引き受けます。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

2. クラッシュダンプを検査するには、mdb ユーティリティーを使用します。

   # /usr/bin/mdb [-k] crashdump-file

   -k

   オペレーティングシステムのクラッシュダンプファイルの場合のカーネルデバッグモードを指定します。

   crashdump-file

   オペレーティングシステムのクラッシュダンプファイルを指定します。

3. クラッシュ状態情報を表示します。

   # /usr/bin/mdb file-name > ::status . . . > ::system . . .

例 17–2 クラッシュダンプを検査する

次の例は、mdb ユーティリティーの出力例を示します。このシステムのシステム情報と /etc/system ファイルに設定されている調整可能パラメータが含まれています。

# /usr/bin/mdb -k unix.0 
Loading modules: [ unix krtld genunix ip nfs ipc ptm ]
> ::status
debugging crash dump /dev/mem (64-bit) from ozlo
operating system: 5.10 Generic (sun4u)
> ::system
set ufs_ninode=0x9c40 [0t40000]
set ncsize=0x4e20 [0t20000]
set pt_cnt=0x400 [0t1024]

クラッシュダンプディレクトリが一杯になった場合に復元する方法 (省略可能)

ここでは、システムがクラッシュしたが、十分な空き容量が savecore ディレクトリに残っておらず、それでも、一部の重要なシステムクラッシュダンプ情報を保存したい場合を考えます。

1. システムをリブートしてからスーパーユーザーとしてログインするか、同等の役割になります。

2. すでにサービスプロバイダに送ってある既存のクラッシュダンプファイルを削除して、savecore ディレクトリ (通常は /var/crash/hostname) を整理します。あるいは、savecore コマンドを実行し、十分な容量を持つ別のディレクトリを指定します。次の手順を参照してください。

3. 手作業で savecore コマンドを実行し、必要なら別の savecore ディレクトリを指定します。

   # savecore [ directory ]

クラッシュダンプの保存を無効または有効にする方法

1. スーパーユーザーになるか、同等の役割を引き受けます。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

2. システム上のクラッシュダンプの保存を有効または無効にします。

   # dumpadm -n | -y

例 17–3 クラッシュダンプの保存を無効にする

次の例は、システムでのクラッシュダンプの保存を無効にします。

# dumpadm -n
      Dump content: all pages
       Dump device: /dev/dsk/c0t1d0s1 (dedicated)
Savecore directory: /var/crash/pluto (minfree = 77071KB)
  Savecore enabled: no

例 17–4 クラッシュダンプの保存を有効にする

次の例は、システムでのクラッシュダンプの保存を有効にします。

# dumpadm -y
      Dump content: all pages
       Dump device: /dev/dsk/c0t1d0s1 (dedicated)
Savecore directory: /var/crash/pluto (minfree = 77071KB)
  Savecore enabled: yes