test

Solaris のシステム管理 (第 2 巻)

第 39 章 システムクラッシュ情報の生成と保存

この章では、クラッシュダンプを有効または無効にする方法と、システムメッセージを表示または収集する方法について説明します。

この章で説明する手順は次のとおりです。

システムクラッシュ

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

システムクラッシュファイルとコアファイル

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

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

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

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

コアファイルは coreadm コマンドで管理します。詳細は、「コアファイルの管理 (coreadm)」を参照してください。

コアファイルの管理 (coreadm)

コアファイルの管理は coreadm コマンドを使用して行います。たとえば、coreadm コマンドを使用して、プロセスコアファイルをすべて同じシステムディレクトリに置くようにシステムを構成できます。Solaris のプロセスやデーモンが異常終了した場合に、特定のディレクトリにあるコアファイルを調べればよいため問題の追跡が容易になります。

Solaris のこれまでのプロセスコアダンプ機能には次の制約がありました。

構成可能なコアファイルの設定

次の 2 つの構成可能な新しいコアファイルの設定は、個別に有効または無効にすることができます。

プロセスが異常終了すると、以前の Solaris リリースと同じように core ファイルが現在のディレクトリに作成されます。しかし、たとえば、グローバルコアファイルの設定が有効で /corefiles/core に設定されていると、プロセスが終了するたびにコアファイルが 2 つ、1 つは現在の作業ディレクトリに、1 つは /corefiles ディレクトリにそれぞれ作成されます。

デフォルトでは Solaris のコアの設定とコアファイルの保存方法は従来と同じです。

拡張されたコアファイル名

グローバルコアファイルディレクトリが有効な場合、次の表に示す変数を使って core ファイルを相互に区別できます。

変数名 

変数の定義 

%p

プロセス ID 

%u

実効ユーザー ID 

%g

実効グループ ID 

%f

実行可能ファイル名 

%n

システムノード名。uname -n の出力と同じ

%m

マシン名。uname -m での出力と同じ

%t

time(2) システム呼び出しの 10 進数

%%

リテラル % 

たとえば、グローバルコアファイル設定が次のように設定されている場合、

/var/core/core.%f.%p

PID 12345 の sendmail プロセスが異常終了すると、次の core ファイルが作成されます。

/var/core/core.sendmail.12345

コアファイル名パターンの設定

コアファイル名パターンは、グローバルに設定したりプロセス単位で設定したりできます。さらに、この設定をシステムリブート後も有効になるように保存するかどうかを指定できます。

たとえば、次の coreadm コマンドでは、init プロセスで起動されたすべてのプロセスに対しグローバルのコアファイルパターンを設定します。このパターンは複数のシステムリブート後も有効です。


$ coreadm -i /var/core/core.%f.%p

グローバルのコア値は /etc/coreadm.conf ファイルに格納されるため、この設定値はシステムリブート後も有効になるように保存されます。

次の coreadm コマンドでは、すべてのプロセスに対しプロセス別コアファイル名パターンを設定します。


$ coreadm -p /var/core/core.%f.%p $$

$$ 記号には、現在実行中のシェルのプロセス ID を指定します。プロセス別コアファイル名パターンは、すべての子プロセスに継承されます。

グローバルまたはプロセス別のコアファイル名パターンを設定したら、これを coreadm -e コマンドで有効にする必要があります。詳細は、次の手順を参照してください。

このコマンドをユーザーの $HOME/.profile または .login ファイルに入れておけば、ユーザーのログインセッションで実行するすべてのプロセスに対しコアファイル名パターンを設定できます。

setuid プログラムを有効にしてコアファイルを作成する

coreadm コマンドを使って setuid プログラムを有効または無効にすれば、次の設定を行うことによって、すべてのシステムプロセスに対して、または各プロセスに対してコアファイルを作成できます。

デフォルトでは、両方のフラグが無効になっています。セキュリティ上の理由により、グローバルコアファイル設定は、/ で始まるフルパス名であることが必要です。スーパーユーザーがプロセス別コアファイルを無効にすると、個別のユーザーがコアファイルを得ることはできなくなります。

setuid コアファイルはスーパーユーザーによって所有され、スーパーユーザーだけに読み取り／書き込み権が与えられます。通常ユーザーは、たとえ setuid コアファイルを生成したプロセスを所有していても、それらのファイルにアクセスできません。

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

現在のコアダンプ構成を表示する方法

現在のコアダンプ構成を表示するには、オプションを指定しないで coreadm コマンドを実行します。


$ coreadm
               global core file pattern: /var/core/core.%f.%p
                 init core file pattern: core
                      global core dumps: enabled
                 per-process core dumps: enabled
                global setid core dumps: enabled
           per-process setid core dumps: disabled
               global core dump logging: disabled

コアファイル名パターンを設定する方法

  1. プロセス別コアファイルを設定するのか、グローバルコアファイルを設定するのかを決めて、次のどちらかの手順に従います。

    1. プロセス別コアファイル名パターンを設定します。


      # coreadm -p $HOME/corefiles/%f.%p $$

    2. グローバルコアファイル名パターンを設定します。

      まずスーパーユーザーになる必要があります。


      # coreadm -g /var/corefiles/%f.%p

コアファイル名パターンを表示する方法

現在のプロセスのコアファイル設定を知るには、次の coreadm コマンドを使用します。$$ 記号には、実行されているシェルのプロセス ID を指定します。


$ coreadm $$
278:    core.%f.%p

スーパーユーザーは coreadm process ID を指定すれば、どのユーザーのコアファイル設定でも照会できます。通常のユーザーは、自分のプロセスのコアファイル設定だけを照会できます。

プロセス別コアファイル設定を有効にする方法

  1. スーパーユーザーになります。

  2. プロセス別コアファイル設定を有効にします。


    # coreadm -e process

  3. 現在のプロセスのコアファイル設定を表示して構成を確認します。


    $ coreadm $$
1180:   /home/kryten/corefiles/%f.%p

グローバルのコアファイル設定を有効にする方法

  1. スーパーユーザーになります。

  2. グローバルのコアファイル設定を有効にします。


    # coreadm -e global -g /var/core/core.%f.%p

  3. 現在のプロセスのコアファイル設定を表示して構成を確認します。


    # coreadm
      global core file pattern: /var/core/core.%f.%p
        init core file pattern: core
             global core dumps: enabled
        per-process core dumps: enabled
       global setid core dumps: disabled
  per-process setid core dumps: disabled
      global core dump logging: disabled

コアファイルの問題解決

エラーメッセージ

NOTICE: 'set allow_setid_core = 1' in /etc/system is obsolete
NOTICE: Use the coreadm command instead of 'allow_setid_core'
原因

setuid コアファイルを許容する古いパラメータが /etc/system ファイルにあります。

解決方法

/etc/system ファイルから allow_setid_core=1 を削除し、coreadm コマンドを使ってグローバル setuid コアファイルの設定を有効にします。

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

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

システムクラッシュダンプ機能

この節では、Solaris 環境でシステムクラッシュダンプ情報を管理する方法を説明します。

dumpadm コマンド

/usr/sbin/dumpadm コマンドは、システムのクラッシュダンプ構成パラメタを管理するコマンドです。次の表で dumpadm の構成パラメタを説明します。

ダンプパラメタ 

説明 

ダンプデバイス 

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

savecore ディレクトリ

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

ダンプ内容 

ダンプするデータの種類、つまりカーネルメモリーとすべてのメモリーのどちらをダンプするかを指定する  

最小空き容量 

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

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

dumpadm コマンドで管理するダンプ構成パラメタは、/etc/dumpadm.conf ファイルに保存されます。

注 -

/etc/dumpadm.conf は、手作業で編集しないでください。システムダンプ構成の整合性が失われる恐れがあります。

dumpadm コマンドの動作

dumpadm コマンドは、システム起動時に /etc/init.d/savecore スクリプトによって呼び出され、/etc/dumpadm.conf ファイルの情報に基づいてクラッシュダンプパラメタの構成を行います。

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

ダンプ構成が完了すると、savecore スクリプトは、/etc/dumpadm.conf ファイルの内容を解析してクラッシュダンプファイルのディレクトリの場所を探します。次に savecore を呼び出してクラッシュダンプがあるかどうかを調べます。さらに、クラッシュダンプディレクトリにある minfree ファイルの内容も調べます。

クラッシュダンプの保存

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

savecore で保存したクラッシュダンプを購入先に送って、システムがクラッシュした原因を解析してもらうことも可能です。購入先にクラッシュダンプファイルを送る場合は、「システムクラッシュ情報の管理 (作業マップ)」にリストされている最初の 2 つの作業を実行してください。

次の節では、dumpadm コマンドを使ってシステムクラッシュ情報を管理する方法を説明します。

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

表 39-1 作業マップ : クラッシュダンプの管理

作業 

説明 

手順の説明 

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

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

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

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

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

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

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

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

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

4. 完全なクラッシュダンプディレクトリから復元する 

(省略可能) システムがクラッシュしたが、savecore ディレクトリに空き容量がない。それでも、一部の重要なシステムクラッシュダンプ情報を保存したい

「フルクラッシュダンプディレクトリから復元する方法 (省略可能)」

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

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

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

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

  1. スーパーユーザーになります。

  2. dumpadm コマンドをオプションなしで実行して、現在のクラッシュダンプ構成を表示します。


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

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

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

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

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

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

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

  1. スーパーユーザーになります。

  2. dumpadm コマンドで、現在のクラッシュダンプ構成を確認します。


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

    上記の構成は、Solaris 8 リリースを実行するシステムのデフォルトダンプ構成です。

  3. dumpadm コマンドでクラッシュダンプ構成を変更します。


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

    -c content

    ダンプするデータの種類、つまり、カーネルメモリーまたはすべてのメモリーのいずれかを指定する。デフォルトはカーネルメモリー 

    -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 コマンドの出力

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

次の例は、すべてのメモリーを専用のダンプデバイス /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. スーパーユーザーになります。

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


    # /usr/sbin/crash [-d crashdump-file] [-n name-list] [-w output-file]

    -d crashdump-file

    システムのメモリーイメージを格納するファイルを指定する。デフォルトのクラッシュダンプファイルは /dev/mem

    -n name-list

    システムのメモリーイメージへのシンボリックアクセスを調べる場合、シンボルテーブル情報を格納するテキストファイルを指定する。デフォルトのファイル名は /dev/ksyms

    -w output-file

    クラッシュセッションからの出力を格納するファイルを指定する。デフォルトは標準出力 

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


    # /usr/sbin/crash
dumpfile = /dev/mem, namelist = /dev/ksyms, outfile = stdout
> status
   .
   .
   .
> size buf proc queue
   .
   .
   .

例 - クラッシュダンプを検査する

次の例は、crash ユーティリティからのサンプル出力を示します。状態とバッファーについての情報、プロセス、および待ち行列のサイズが表示されます。 


# /usr/sbin/crash
dumpfile = /dev/mem, namelist = /dev/ksyms, outfile = stdout
> status
system name:	SunOS
release:	5.8
node name:	earth
version:	s28_25
machine name:	sun4m
time of crash:	Wed Jun 30 16:02:31 1999
age of system:	18 min.
panicstr:	
panic registers:
	pc: 0      sp: 0
> size buf proc queue
120
1808
96

フルクラッシュダンプディレクトリから復元する方法 (省略可能)

ここでは、システムがクラッシュしてもメモリーイメージを格納する十分な空き容量が savecore ディレクトリにないが、それでも、一部の重要なシステムクラッシュダンプ情報を保存するものとします。

  1. システムがリブートした後で、スーパーユーザーとしてログインします。

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

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


    # savecore [ directory ]

クラッシュダンプの保存を有効または無効にする方法 (省略可能)

  1. スーパーユーザーになります。

  2. dumpadm コマンドにより、システム上にクラッシュダンプを保存するかどうかを指定します。

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

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


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

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

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


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