Sun Java System Directory Server Enterprise Edition 6.3 トラブルシューティングガイド

クラッシュのトラブルシューティング

この節では、クラッシュした Directory Server プロセスのトラブルシューティングを開始する方法について説明します。クラッシュの考えられる原因、問題を特定するために収集する必要のある情報、収集した情報の分析方法について説明します。

クラッシュの考えられる原因

クラッシュの原因には、次に示す要素の 1 つまたは複数が考えられます。

バッファーオーバーフロー
リソース (メモリー、ディスク、ファイル記述子など) の不足
メモリー割り当ての問題 (ダブルフリー、未割り当ての空き記憶領域など)
NULL の逆参照
その他のプログラムエラー

Directory Server プロセスがクラッシュする場合、Sun サポートセンターを使用してサービスリクエストを開始する必要があります。

クラッシュに関するデータの収集

この節では、サーバーがクラッシュしたときに収集する必要のあるデータについて説明します。収集すべきもっとも重要なデータは、コアファイルです。

注 –

クラッシュした Directory Server プロセスについて Sun サポートセンターに連絡する場合、コアファイルとログを提出する必要があります。

コアファイルの生成

コアファイルおよびクラッシュダンプは、プロセスまたはアプリケーションが異常終了したときに生成されます。サーバーがクラッシュしたときに Directory Server がコアファイルを生成できるように、システムを設定します。コアファイルには、クラッシュ時の Directory Server プロセスのスナップショットが含まれます。これは、クラッシュの原因を特定するために不可欠な場合があります。コアファイルは errors ログと同じディレクトリに書き込まれます。デフォルトでは、このディレクトリは instance-path /logs/ です。コアファイルにはエントリキャッシュが含まれるため、サイズが非常に大きくなる場合があります。

コアファイルが自動的に生成されない場合は、次の表に示すコマンドを使用してコアダンプを許可するようにオペレーティングシステムを設定してから、次のクラッシュを待ってデータを取得します。

Solaris

coreadm

または、

ulimit -c unlimited
ulimit -H -c unlimited

Linux

ulimit -c unlimited
ulimit -H -c unlimited

HPUX/AIX

ulimit -c

Windows

Windows crashdump

たとえば Solaris OS では、次のコマンドを使用してアプリケーションのコアファイル生成を有効にします。

# coreadm -g /path-to-file/%f.%n.%p.core -e global -e process \
 -e global-setid -e proc-setid -e log

path-to-file には、生成するコアファイルのフルパスを指定します。ファイルの名前には、実行可能ファイル名 (%f)、システムノード名 (%n)、およびプロセス ID (%p) が使用されます。

コアファイル生成を有効にしてもシステムがコアファイルを生成しない場合は、オペレーティングシステムで設定されているファイルサイズ書き込み制限の変更が必要な可能性があります。次に示すように ulimit コマンドを使用して、コアファイルおよびスタックセグメントの最大サイズを変更します。

# ulimit -c unlimited 
# ulimit -s unlimited

次に示すように -a オプションを使用して、制限が正しく設定されていることを確認します。

# ulimit -a
time(seconds)        unlimited
file(blocks)         unlimited
data(kbytes)         unlimited
stack(kbytes)        unlimited
coredump(blocks)     unlimited
nofiles(descriptors) 256
vmemory(kbytes)      unlimited

Red Hat Linux および Windows でのコアファイル生成の設定については、『Sun Gathering Debug Data for Sun Java System Directory Server 5』の「Configuring the Operating System to Generate Core Files」を参照してください。

次に、kill -11 process-id コマンドを使用して、アプリケーションがコアファイルを生成可能であることを確認します。コアの生成先は、指定したディレクトリ内またはデフォルトの instance-name/logs ディレクトリ内になります。

# cd /var/cores
# sleep 100000 &
[1] process-id
# kill -11 process-id
# ls

コアライブラリと共用ライブラリの取得

コアファイルを分析するため、slapd プロセスに関連付けられたすべてのライブラリおよびバイナリを取得します。pkg_app スクリプトを使用してライブラリを収集します。pkg_app スクリプトは、実行可能ファイルとそのすべての共用ライブラリを、圧縮された 1 つの tar ファイルにパッケージ化します。アプリケーションのプロセス ID、および開くコアファイルの名前 (必要な場合) を指定します。pkg_app スクリプトの詳細については、「Solaris での pkg_app スクリプトの使用」を参照してください。

superuser として、pkg_app スクリプトを次のように実行します。

# pkg_app server-pid core-file

注 –

コアファイルを指定せずに pkg_app スクリプトを実行することもできます。これにより、スクリプトの出力サイズが小さくなります。あとで、変数をコアファイルの正しい場所に設定する必要があります。

補足情報

問題発生時に作成されたログファイルを表示するには、次のファイルを確認します。

# install-path/instance-name/logs/errors*
# install-path/instance-name/logs/access*

クラッシュが、オペレーティングシステムのディスクまたはメモリー容量の不足に関連するものである場合は、システムログを取得します。たとえば、Solaris OS では、 /var/adm/messages ファイルおよび /var/log/syslogs ファイルを参照して、ハードウェアまたはメモリーの障害を確認します。

完全な出力を取得するには、次のコマンドを使用します。

# cd install-path/bin/slapd/server
# ./ns-slapd -D install-path/instance-name -V

クラッシュデータの分析

Directory Server がクラッシュする際には、常にコアが生成されます。このコアファイルおよび ns-slapd バイナリディレクトリから取得したコアファイルのプロセススタックを使用して、問題を分析できます。

この節では、Solaris OS でコアファイルクラッシュデータを分析する方法について説明します。

Solaris でのコアファイルの確認

コアファイルを取得したあとで、このファイルに対して pstack および pmap Solaris ユーティリティーを実行します。pmap ユーティリティーは、仮想アドレスのリストを含むプロセスマップを表示します。仮想アドレスは、動的ライブラリの読み込み先であるとともに、変数が宣言される場所でもあります。pstack ユーティリティーにより、プロセススタックが表示されます。これは、プロセス内のスレッドごとに、プロセスの終了時または pstack コマンドの実行時にスレッドが実行していた命令のスタックを示します。

これらのユーティリティーは、ns-slapd バイナリ root-dir/bin/slapd/server を含むディレクトリから実行する必要があります。次に示すようにユーティリティーを実行します。

# pstack core-file

# pmap core-file

pstack ユーティリティーの結果がほぼ空である場合は、すべての出力行が次のようになります。

0002c3cc ???????? (1354ea0, f3400, 1354ea0, 868, 2fc, 1353ff8)

pstack の出力がこのような場合は、ns-slapd バイナリディレクトリからこのユーティリティーを実行していることを確認してください。ns-slapd バイナリディレクトリからこのユーティリティーを実行していなかった場合は、このディレクトリに移動してユーティリティーを再度実行します。

pstack コマンドの代わりに mdb コマンドを使用してもコアのスタックを確認できます。次のように mdb コマンドを実行します。

# mdb $path-to-executable $path-to-core
$C to show the core stack
$q to quit

mdb および pstack コマンドの出力から、クラッシュ時のプロセススタックに関する有用な情報を入手できます。mdb $C コマンドの出力から、クラッシュを引き起こしたスレッドを特定できます。

Solaris 8 および 9 では、多くの場合、pstack 出力の最初のスレッドにクラッシュの原因となったスレッドが含まれます。Solaris 10 では、mdb を使用してクラッシュの原因となったスレッドを特定します。pstack コマンドを使用する場合は、lwp-park、poll、および pollsys を含まないスレッドを検索して、スタックを分析します。

たとえば、プラグイン関数の呼び出し時に、次のコアプロセススタックが発生します。

core '../../../slapd-psvmrr3-27/logs/core' of 18301:    ./ns-slapd \
-D /opt/iplanet/servers/slapd-psvmrr3-27 -i /opt/iplanet/se
-----------------  lwp# 13 / thread# 25  --------------------
 ff2b3148 strlen   (0, fde599fb, 0, fbed1, 706d2d75, fde488a8) + 1c
 ff307ef8 sprintf  (7fffffff, fde488a0, fde599d8, fde599ec, 706d2d75, fde599fc) \
+ 3c
 fde47cf8 ???????? (1354ea0, 850338, fde59260, e50243, 923098, 302e3800) + f8
 fde429cc ???????? (1354ea0, 3, 440298, 154290, 345c10, 154290) + 614
 ff164018 plugin_call_exop_plugins (1354ea0, 8462a0, d0c, ff1e7c70, ff202a94, \
1353ff8) + d0
 0002c3cc ???????? (1354ea0, f3400, 1354ea0, 868, 2fc, 1353ff8)
 00025e08 ???????? (0, 1353ff8, fdd02a68, f3400, f3000, fbc00)
 fef47d18 _pt_root (362298, fe003d10, 0, 5, 1, fe401000) + a4
 fed5b728 _thread_start (362298, 0, 0, 0, 0, 0) + 40

コアから取得したプロセススタックを分析する際は、スレッド中央の操作に注目します。下部のプロセスは分析するには一般的過ぎ、上部のプロセスは限定的過ぎます。スレッド中央のコマンドは Directory Server に固有のものであるため、処理のどの時点で操作が失敗したかを識別する助けになります。上の例では、plugin_call_exop_plugins プロセス呼び出しで、カスタムプラグイン内の外部操作の呼び出し時に問題が発生したことを示しています。

Directory Server 関連の問題の場合は、問題の原因である可能性のもっとも高い関数呼び出しを使って SunSolve で検索し、この関数呼び出しに関連する問題を参照できます。SunSolve には、http://sunsolve.sun.com/ でアクセスできます。

発生している問題に関連する問題が見つかった場合は、それが実行中の Directory Server のバージョンに適用されるか確認します。バージョンの情報を取得するには、次のコマンドを使用します。

# ns-slapd -V

コアファイルの基本的な分析を行っても問題を特定できない場合は、pkg_app スクリプトを使ってバイナリおよびライブラリを収集し、Sun サポートセンターに連絡してください。