この章では、クラッシュダンプを有効または無効にする方法と、システムメッセージを表示または収集する方法について説明します。
この章で説明する手順は次のとおりです。
ハードウェアの障害、入出力の問題、ソフトウェアエラーなどが原因でシステムがクラッシュすることがあります。システムがクラッシュすると、システムはエラーメッセージをコンソールに表示し、物理メモリーのコピーをダンプデバイスに書き込みます。その後、システムは自動的にリブートします。システムがリブートすると、savecore コマンドが実行され、ダンプデバイスのデータを取り出して保存されたクラッシュダンプを savecore ディレクトリに書き込みます。このクラッシュダンプファイルは、サポートプロバイダにとって、問題を診断する上で貴重な情報となります。
システムクラッシュの後で自動的に実行される savecore コマンドは、ダンプデバイスからクラッシュダンプ情報を取り出し、unix.X と vmcore.X という 1 対のファイルを作成します。X はダンプの通し番号です。これらのファイルは 2 つで、保存されたシステムクラッシュダンプの情報を表します。
クラッシュダンプファイルはコアファイルと混同されることがあります。コアファイルは、アプリケーションが異常終了したときに書き込まれるユーザーアプリケーションのイメージです。
クラッシュダンプファイルは、あらかじめ決められたディレクトリに保存されます。これはデフォルトでは /var/crash/hostname です。以前の Solaris リリースでは、システムを手動で有効にして物理メモリーのイメージをクラッシュダンプファイルに保存しない限り、システムがリブートされた時にクラッシュダンプファイルが上書きされていました。このリリースでは、クラッシュダンプファイルの保存がデフォルトで有効です。
システムクラッシュ情報は dumpadm コマンドで管理します。詳細は、「システムクラッシュダンプ情報の管理 (dumpadm)」を参照してください。
コアファイルは coreadm コマンドで管理します。詳細は、「コアファイルの管理 (coreadm)」を参照してください。
コアファイルの管理は coreadm コマンドを使用して行います。たとえば、coreadm コマンドを使用して、プロセスコアファイルをすべて同じシステムディレクトリに置くようにシステムを構成できます。Solaris のプロセスやデーモンが異常終了した場合に、特定のディレクトリにあるコアファイルを調べればよいため問題の追跡が容易になります。
Solaris のこれまでのプロセスコアダンプ機能には次の制約がありました。
プロセス core ファイルはそれぞれの現在の作業ディレクトリに置かれるため、すべての Solaris デーモンが core ファイルを互いに上書きします (一般に Solaris デーモンは初期化の過程で chdir により作業ディレクトリをルート (/) ディレクトリに変更します)。
statd など多くのシステムデーモンは setuid 操作を行いますが、セキュリティ上の理由から、問題が起きてもコアファイルを生成しません。
次の 2 つの構成可能な新しいコアファイルの設定は、個別に有効または無効にすることができます。
プロセス別コアファイルの設定にはデフォルトで core が使用されます。この設定はデフォルトで有効になっています。プロセス別コアファイルの設定が有効になっていると、プロセスが異常終了したときに core ファイルが生成されます。プロセス別の設定は、親プロセスから新しいプロセスに継承されます。
プロセス別コアファイルは生成されるとプロセスの所有者によって所有され、所有者には読み取り/書き込み権が与えられます。所有者だけがこのファイルを表示できます。
グローバルコアファイルの設定にはデフォルトで core が使用されます。この設定はデフォルトで無効になっています。この設定が有効になっていると、プロセス別コアファイルの設定と同じ内容のコアファイルがグローバルコアファイルの設定に追加で作成されます。
グローバルコアファイルは生成されるとスーパーユーザーによって所有され、スーパーユーザーだけに読み取り/書き込み権が与えられます。アクセス権のないユーザーはこのファイルを表示できません。
プロセスが異常終了すると、以前の Solaris リリースと同じように core ファイルが現在のディレクトリに作成されます。しかし、たとえば、グローバルコアファイルの設定が有効で /corefiles/core に設定されていると、プロセスが終了するたびにコアファイルが 2 つ、1 つは現在の作業ディレクトリに、1 つは /corefiles ディレクトリにそれぞれ作成されます。
デフォルトでは Solaris のコアの設定とコアファイルの保存方法は従来と同じです。
setuid プロセスは、グローバルの設定やプロセス別の設定を使ってコアファイルを生成することはありません。
グローバルコアファイルディレクトリが有効な場合、次の表に示す変数を使って 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 ファイルに入れておけば、ユーザーのログインセッションで実行するすべてのプロセスに対しコアファイル名パターンを設定できます。
coreadm コマンドを使って setuid プログラムを有効または無効にすれば、次の設定を行うことによって、すべてのシステムプロセスに対して、または各プロセスに対してコアファイルを作成できます。
グローバル setuid オプションが有効になっていると、グローバルコアファイル設定に従って、システムのすべての setuid プログラムが core ファイルを作成します。
プロセス別 setuid オプションが有効になっていると、プロセス別コアファイル設定に従って、特定の setuid プロセスが core ファイルを作成します。
デフォルトでは、両方のフラグが無効になっています。セキュリティ上の理由により、グローバルコアファイル設定は、/ で始まるフルパス名であることが必要です。スーパーユーザーがプロセス別コアファイルを無効にすると、個別のユーザーがコアファイルを得ることはできなくなります。
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 |
現在のプロセスのコアファイル設定を知るには、次の coreadm コマンドを使用します。$$ 記号には、実行されているシェルのプロセス ID を指定します。
$ coreadm $$ 278: core.%f.%p |
スーパーユーザーは coreadm process ID を指定すれば、どのユーザーのコアファイル設定でも照会できます。通常のユーザーは、自分のプロセスのコアファイル設定だけを照会できます。
スーパーユーザーになります。
プロセス別コアファイル設定を有効にします。
# coreadm -e process |
現在のプロセスのコアファイル設定を表示して構成を確認します。
$ coreadm $$ 1180: /home/kryten/corefiles/%f.%p |
スーパーユーザーになります。
グローバルのコアファイル設定を有効にします。
# coreadm -e global -g /var/core/core.%f.%p |
現在のプロセスのコアファイル設定を表示して構成を確認します。
# 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 コアファイルの設定を有効にします。
この節では、Solaris 環境でシステムクラッシュ情報を管理する方法を説明します。
この節では、Solaris 環境でシステムクラッシュダンプ情報を管理する方法を説明します。
新しい dumpadm コマンドを使用すると、システム管理者はオペレーティングシステムのクラッシュダンプを構成できます。dumpadm 構成パラメタでは、ダンプ内容、ダンプデバイス、クラッシュダンプファイルが保存されるディレクトリなどを指定します。dumpadm コマンドの詳細は、「dumpadm コマンド」を参照してください。
ダンプデータは、圧縮した形式でダンプデバイスに格納されます。カーネルのクラッシュダンプイメージは 4G バイトを超える場合があります。データを圧縮することにより、ダンプが速くなり、ダンプデバイスのディスク領域も少なくてすみます。
専用のダンプデバイス (スワップ領域ではなく) がダンプ構成の一部にあると、クラッシュダンプファイルの保存はバックグラウンドで行われます。つまり、ブートシステムは、savecore コマンドが完了するのを待たなくても、次の手順に進むことができます。大容量のメモリーを搭載したシステムでは、savecore コマンドが完了する前にシステムが使用可能になります。
savecore コマンドで生成されるシステムクラッシュダンプファイルは、デフォルトで保存されます。
savecore -L コマンドは、移動中の Solaris オペレーティング環境でクラッシュダンプを取得できる新しい機能です。たとえば、性能に問題が発生しているときやサービスが停止しているときなどにメモリーのスナップショットをとって、実行中のシステムの問題を解決するのに使用します。システムが実行中で、一部のコマンドがまだ使用できる場合は、savecore -L を使用してシステムのスナップショットをダンプデバイスに保存し、クラッシュダンプファイルをただちに savecore ディレクトリに書き込むことができます。システムが実行中であるため、専用のダンプデバイスを構成してあれば、savecore -L を使用するだけでダンプを作成できます。
/usr/sbin/dumpadm コマンドは、システムのクラッシュダンプ構成パラメタを管理するコマンドです。次の表で dumpadm の構成パラメタを説明します。
ダンプパラメタ |
説明 |
---|---|
ダンプデバイス |
システムがクラッシュしたときにダンプデータを一時的に保存するデバイス。ダンプデバイスがスワップ領域でない場合は、savecore がバックグラウンドで実行されるため、ブートプロセスの速度が上がる |
savecore ディレクトリ |
システムのクラッシュダンプファイルを保存するディレクトリ |
ダンプ内容 |
ダンプするデータの種類、つまりカーネルメモリーとすべてのメモリーのどちらをダンプするかを指定する |
最小空き容量 |
クラッシュダンプファイルを保存した後で savecore ディレクトリに必要な最小空き容量。空き容量を指定しないと、デフォルトで 1M バイトになる |
詳細は、dumpadm(1M) のマニュアルページを参照してください。
dumpadm コマンドで管理するダンプ構成パラメタは、/etc/dumpadm.conf ファイルに保存されます。
/etc/dumpadm.conf は、手作業で編集しないでください。システムダンプ構成の整合性が失われる恐れがあります。
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 コマンドを使ってシステムクラッシュ情報を管理する方法を説明します。
作業 |
説明 |
手順の説明 |
---|---|---|
1. 現在のクラッシュダンプ構成を表示する |
dumpadm コマンドを使用して、現在のクラッシュダンプ構成を表示する | |
2. クラッシュダンプ構成を変更する |
dumpadm コマンドを使用して、ダンプするデータの種類、システムが専用のダンプデバイスを使用するかどうか、クラッシュダンプファイルを保存するディレクトリ、およびクラッシュダンプファイルが書き込まれた後に残っていなければならない容量を指定する | |
3. クラッシュダンプファイルを調べる |
crash コマンドを使用して、クラッシュダンプファイルを表示する | |
4. 完全なクラッシュダンプディレクトリから復元する |
(省略可能) システムがクラッシュしたが、savecore ディレクトリに空き容量がない。それでも、一部の重要なシステムクラッシュダンプ情報を保存したい | |
5. クラッシュダンプファイルの保存を有効または無効にする |
(省略可能) dumpadm コマンドを使用して、クラッシュダンプファイルの保存を有効または無効にする。デフォルトでは、クラッシュダンプファイルは保存される |
スーパーユーザーになります。
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 ディレクトリに保存される
システムクラッシュダンプファイルの保存は有効に設定されている
スーパーユーザーになります。
dumpadm コマンドで、現在のクラッシュダンプ構成を確認します。
# dumpadm Dump content: kernel pages Dump device: /dev/dsk/c0t3d0s1 (swap) Savecore directory: /var/crash/pluto Savecore enabled: yes |
上記の構成は、Solaris 8 リリースを実行するシステムのデフォルトダンプ構成です。
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 |
スーパーユーザーになります。
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 |
クラッシュセッションからの出力を格納するファイルを指定する。デフォルトは標準出力 |
クラッシュ状態情報を表示します。
# /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 ディレクトリにないが、それでも、一部の重要なシステムクラッシュダンプ情報を保存するものとします。
システムがリブートした後で、スーパーユーザーとしてログインします。
すでにサービスプロバイダに送ってある既存のクラッシュダンプファイルを削除して、savecore ディレクトリ (通常は /var/crash/hostname) を整理します。あるいは、savecore コマンドを実行し、十分な容量を持つ別のディレクトリを指定します (次の手順を参照してください)。
手作業で savecore コマンドを実行し、必要なら別の savecore ディレクトリを指定します。
# savecore [ directory ] |
次の例は、システムでのクラッシュダンプの保存を無効にします。
# 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 |