test

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

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

この章では、Oracle Solaris OS でシステムクラッシュ情報を管理する方法を説明します。

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

システムクラッシュ情報の管理に関する新機能

この節では、Oracle Solaris でシステム資源を管理するための新機能、または機能の変更について説明します。

高速クラッシュダンプ機能

Oracle Solaris 10 9/10: この機能強化により、システムではより短時間に、少ない容量でクラッシュダンプを保存できるようになりました。クラッシュダンプが完了するまでの所要時間は、プラットフォームに応じて 2 倍から 10 倍高速化されています。クラッシュダンプを savecore ディレクトリ内に保存するのに必要なディスク容量は、同じ比率で減少しています。クラッシュダンプファイルの作成と圧縮を高速化するため、高速クラッシュダンプ機能は、大規模システムの使用頻度が低い CPU を利用します。新しいクラッシュダンプファイルの vmdump.n は、vmcore.n ファイルと unix.n ファイルの圧縮されたバージョンです。圧縮されたクラッシュダンプは、より迅速にネットワーク上を移動し、オフサイトで分析することができます。ダンプファイルを mdb ユーティリティなどのツールで使うためには、最初に圧縮解除する必要があることに注意してください。ダンプファイルはローカルで、またはリモートから savecore コマンドを使用して、圧縮解除することができます。

新しいクラッシュダンプ機能をサポートするため、dumpadm コマンドに -z オプションが追加されました。このオプションを使用して、ダンプを圧縮または非圧縮のどちらの形式で保存するかを指定します。デフォルトは圧縮した形式です。

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

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

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

作業 

説明 

参照先 

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

dumpadm コマンドを使用して、現在のクラッシュダンプ構成を表示する

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

2. クラッシュダンプ構成を変更する 

dumpadm コマンドを使用して、ダンプするデータの種類、システムが専用のダンプデバイスを使用するかどうか、クラッシュダンプファイルを保存するディレクトリ、およびクラッシュダンプファイルが書き込まれた後に残っていなければならない容量を指定する

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

3. クラッシュダンプファイルを調べる 

mdb コマンドを使用して、クラッシュダンプファイルを表示する

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

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

システムがクラッシュした際、 savecore ディレクトリに十分な空き容量がなくても、一部の重要なシステムクラッシュダンプ情報を保存したい場合

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

5. (省略可能) クラッシュダンプファイルの保存を有効または無効にする 

dumpadm コマンドを使用して、クラッシュダンプファイルの保存を有効または無効にする。デフォルトでは、クラッシュダンプファイルは保存される

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

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

ハードウェアの障害、入出力の問題、ソフトウェアエラーなどが原因でシステムがクラッシュすることがあります。システムがクラッシュすると、システムはエラーメッセージをコンソールに表示し、物理メモリーのコピーをダンプデバイスに書き込みます。その後、システムは自動的にリブートします。システムがリブートするときに、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 ボリュームマネージャーの管理下に置くことはできますが (この方法を推奨します)、ダンプデバイスは別に確保してください。

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

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

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

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

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

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


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

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

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

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

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

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

    • クラッシュダンプを圧縮した形式で保存する

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

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

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

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


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

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

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


    #  /usr/sbin/dumpadm  [-nuy] [-c content-type] [-d dump-device] [-m mink | minm | min%]
[-s savecore-dir] [-r root-dir] [-z on | off]
    -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 コマンドの出力

    -u

    /etc/dumpadm.conf ファイルの内容に基づいてカーネルダンプ構成を強制的に更新します。

    -y

    リブート時に自動的に savecore コマンドを実行するようにダンプ構成を変更します。このダンプ設定では、このコマンドの自動実行がデフォルトです。

    -z on | off

    リブート時の savecore コマンドの動作を制御するために、ダンプ構成を変更します。on 設定では、圧縮した形式でのコアファイルの保存が有効になります。off 設定では、クラッシュダンプファイルを自動的に圧縮解除します。クラッシュダンプファイルはサイズが非常に大きくなる場合があり、圧縮した形式で保存すれば必要なシステム領域が小さくなるため、デフォルトは on です。

例 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
   Save compressed: on
 # 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
    Save compressed: on

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

  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]

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

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

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

  2. すでにサービスプロバイダに送ってある既存のクラッシュダンプファイルを削除して、savecore ディレクトリ (通常は /var/crash/hostname) を整理します。

    • 別の方法として、savecore コマンドを手作業で実行し、十分なディスク容量がある代替ディレクトリを指定することができます。


      # savecore [ directory ]

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

  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
   Save Compressed: on
例 17–4 クラッシュダンプの保存を有効にする

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


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