test

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

第 4 章 Directory Proxy Server のトラブルシューティング

この章では、Directory Proxy Server で発生する問題をトラブルシューティングする方法について説明します。次の項があります。

一般的な Directory Proxy Server データの収集

発生している問題の種類に関係なく、収集し、必要に応じて Sun サポートに提供しなければならない最小限のデータセットがあります。

Directory Proxy Server のバージョン情報の収集

以降の節では、現在および以前のバージョンの Directory Proxy Server の設定情報を収集する方法について説明します。

Directory Proxy Server 6.3 のバージョン情報の収集

Directory Proxy Server 6.3 のバージョン情報を収集します。この情報は、instance-dir/logs/error ファイルから入手できます。たとえば、エラーログにはバージョン情報が次のように表示されます。


[21/May/2007:18:01:27 +0200] - STARTUP    - INFO  - \
Sun-Java(tm)-System-Directory-Proxy-Server/6.1 B2007.134.2156 started \
on host server1 in directory /local/dps.3333

Directory Proxy Server 5.x のバージョン情報の収集

移行した Directory Proxy Server 5.x インスタンスを使用している場合は、次の方法でバージョン情報を収集します。


# install-path/bin/dps/server/bin/ldapfwd -v

UNIX および Linux システムでは、次のエラーが表示されることがあります。


ld.so.1: ldapfwd: fatal: libnss3.so: open failed: No such file or directory

このエラーが表示された場合は、Directory Proxy Server ライブラリがロードパスに含まれるように LD_LIBRARY_PATH を設定します。たとえば sh を使用する場合は、次のコマンドを使用します。


# export LD_LIBRARY_PATH=install-path/lib

冗長モードでの dpadm コマンドの実行

dpadm コマンドを冗長モードで実行すると、インスタンスの作成や削除、データのバックアップなどで発生する問題のトラブルシューティングに役立つ情報が生成されます。次のように、dpadm を冗長モードで実行します。


# dpadm -v

Directory Proxy Server の設定情報の収集

以降の節では、現在および以前のバージョンの Directory Proxy Server の設定情報を収集する方法について説明します。

Directory Proxy Server 6.3 の設定情報の収集

Directory Proxy Server 6.3 の設定情報を収集します。この情報は、instance-dir/logs/error ファイルから入手できます。たとえば、エラーログには設定情報が次のように表示されます。


user@server1 local]$ more dps.3333/logs/errors
[21/May/2007:18:01:27 +0200] - STARTUP    - INFO  - Global \
log level INFO (from config)
[21/May/2007:18:01:27 +0200] - STARTUP    - INFO  - Logging \
Service configured
[21/May/2007:18:01:27 +0200] - STARTUP    - INFO  - Java \
Version: 1.5.0_09 (Java Home: /local/jre)
[21/May/2007:18:01:27 +0200] - STARTUP    - INFO  - Java Heap Space: \
Total Memory (-Xms) = 246MB, Max Memory (-Xmx) = 246MB
[21/May/2007:18:01:27 +0200] - STARTUP    - INFO  - Operating System: \
Linux/i386 2.6.17-1.2139_FC5smp

Directory Proxy Server 5.x の設定情報の収集

次のように、Directory Proxy Server 5.x の設定情報を収集します。


# cd install-path/bin/dps_utilities
# ./dpsconfig2ldif -t install-path/dps-name/etc/tailor.txt.backup \
-o /tmp/DPS_tailor_Config.ldif

DPS_tailor_Config.ldif ファイルには、次の書式の設定情報が含まれます。


Begin configuration_url:file:///server-root/instance/
etc/tailor.ldif#cn=dps-instance1,cn=Sun ONE Directory Proxy Server,
cn=ServerGroup (1),cn=instance1.example.com,ou=example.com,
o=NetscapeRoot End

Directory Proxy Server のログ情報の収集

Directory Proxy Server のログを収集します。デフォルトでは、ログは次のディレクトリ内に格納されます。


instance-path/logs

Sun サポートに情報を提供する場合は、関係するさまざまな Directory Server から入手可能な一般的な Directory Server データも含めてください。この一般データには、Directory Server のバージョンと、Directory Server のアクセスログ、エラーログ、および監査ログが含まれます。Directory Server の一般データの収集について詳しくは、「汎用データの収集」を参照してください。

JDBC バックエンド、SQL データベース、Oracle データベースなど、その他のバックエンドサーバーを使用している場合は、それらの一般情報も含めます。

Directory Proxy Server のインストールに関する問題のトラブルシューティング

この節では、Directory Proxy Server のインストールに関する問題のデバッグに役立つ手順を示します。次の内容が含まれます。

Directory Proxy Server 5.2 のインストールの失敗のトラブルシューティング

pa$$word のように、パスワードにドル記号 ($) 文字が含まれる場合は、インストールが失敗することがあります。たとえば、次のようなエラーメッセージが表示されます。


[4] stderr > Can't read "word" no such variable

インストーラはパスワードを解析する際に、ドル記号のあとのテキスト $word を変数として解釈しますが、この変数は存在しません。

ドル記号文字を含まないパスワードに変更してください。

Windows での Directory Proxy Server 5.2 の起動時のトラブルシューティング

Windows 上で Directory Proxy Server 5.2 の起動に失敗する場合、次の点を確認してください。

  1. dps、sunOne、idar、dar、iplanet などのキーがレジストリに残っていないことを確認します。

  2. C:\WINNT\System32 ディレクトリ内に存在する製品レジストリファイルを削除します。

  3. マシンを再起動します。

    Directory Proxy Server の再インストールを試みます。

Localmachine->system->controlset001->services->admin52 エントリを手動で削除することが必要な場合もあります。次のエラーが管理サーバーのインストールログに記録される場合、このエントリが問題を引き起こしている可能性があります。


Error: Writing Administration Server service keys to the Windows registry... failed. (エラー: Windows 
レジストリへの管理サーバーサービスキーの書き込みに失敗しました)

Directory Proxy Server プロセスの問題のトラブルシューティング

この節では、次の手順について説明します。

プロセスのトラブルシューティングツールの概要

Solaris および Java に付属するツールに、プロセスに関する問題のトラブルシューティングに利用できるものがあります。以降の節で、もっとも有用性の高いツールの概要を説明します。

Directory Proxy Server 6.3 での Java ツールの使用

Directory Proxy Server 6.3 は Pure Java アプリケーションであるため、JDK 1.5 に付属の Java ツールを問題のトラブルシューティングに使用できます。次のツールが含まれます。

Solaris では、これらのツールは次の場所に存在します。


/usr/lang/JAVA/jdk1.5.0_03/solaris-sparc/bin

JVM には、JConsole (Java Monitoring and Management Console) ツールと呼ばれる、Java 仮想マシンを監視するためのグラフィカルツールも含まれます。このツールは、Java プラットフォーム上で JMX (Java Management Extension) テクノロジを使用して稼働しているアプリケーションのパフォーマンスおよびリソース消費に関する情報を、Java 仮想マシンを使用して提供します。JConsole を使用して、Java プラットフォームで稼働しているアプリケーションに関する情報を確認できます。JConsole は、メモリー使用状況、スレッド使用状況、クラスローディング、および JVM パラメータに関する情報およびチャートを提供します。

Unix プラットフォームでは、スレッドダンプの取得に kill -QUIT process-id コマンドを使用してもうまくいかない場合に、jstack が使用されます。

Directory Proxy Server 5.x での Solaris ツールの使用

Solaris に含まれるプロセスツールのコレクションを使用すると、ハングアップしたプロセス、クラッシュしたプロセス、メモリー使用量の問題など、プロセスに関する問題の詳細を収集するのに役立ちます。次のツールが含まれます。

ハングアップまたは応答しない Directory Proxy Server プロセスのトラブルシューティング

この節では、応答しないまたはハングアップした Directory Proxy Server プロセスのトラブルシューティングについて説明します。まったく応答しないプロセスを、ハングアップと呼びます。この節の以降の部分では、ハングアップに関するデータを収集および分析する方法について説明します。

Solaris での Directory Proxy Server 6.3 のハングアップに関するデータの収集

jstat ツールは、CPU の使用量をスレッドごとに示します。jstat ツールの実行と同時に jstack ユーティリティーを使用してスレッドスタックを収集する場合は、jstack の出力を使って問題発生時のスレッドの動作を確認できます。jstack および jstat ツールを同時に何度も実行していくと、問題が同じスレッドで発生していたのか、また同じ関数呼び出しで発生していたのかを確認できます。

実行中の Directory Proxy Server のプロセス ID を取得するには、jps コマンドを使用します。たとえば、Solaris では、次のようにこのコマンドを実行します。


# jps
8393 DistributionServerMain
2115 ContainerPrivate
21535 startup.jar
16672 Jps
13953 swupna.jar

次のように使用状況の情報を収集します。


# ./scp DPS-PID

DPS-PID フィールドには、応答しないプロセスの PID を指定します。

Solaris およびその他の UNIX プラットフォームでは、次のように truss コマンドを使用して、クラッシュ時に発生するシステムコールを表示します。


truss -o /tmp/trace.txt -ealf -rall -wall -vall -p 21362

値 21362 は、応答しないプロセスの PID に対応します。

Solaris での Directory Proxy Server 5.x のハングアップに関するデータの収集および分析

prstat ツールは、CPU の使用量をスレッドごとに示します。prstat ツールの実行と同時に pstack ユーティリティーを使用してプロセススタックを収集する場合は、pstack の出力を使って問題発生時のスレッドの動作を確認できます。prstat および pstack ツールを同時に何度も実行していくと、問題が同じスレッドで発生していたのか、また同じ関数呼び出しで発生していたのかを確認できます。

注 –

Linux では、Solaris の pstack ユーティリティーの代わりに lsstack または pstack コマンドを使用します。

次に示すのは、これらのツールの実行を自動化するスクリプトです。


cat scp
#!/bin/sh  

i=0 
while [ "$i" -lt "10" ] 
do
         echo "$i\n"
         date=`date "+%y%m%d:%H%M%S"`
         prstat -L -p $1 0 1 > /tmp/prstat.$date
         pstack $1 > /tmp/pstack.$date
         i=`expr $i + 1`;
         sleep 1 
done

[ "$i" -lt "10" ] 行の値 10 は、トラブルシューティング中の問題が発生する時間に合わせて増減できます。この調整により、完全なプロセスデータセットを収集して問題のトラブルシューティングに役立てることができます。このようにして、問題に関係する完全なプロセスデータセットの入手が可能になります。

次のように使用状況の情報を収集します。


# ./scp DPS-PID

DPS-PID フィールドには、応答しないプロセスの PID を指定します。

Solaris およびその他の UNIX プラットフォームでは、次のように truss コマンドを使用して、クラッシュ時に発生するシステムコールを表示します。


truss -o /tmp/trace.txt -ealf -rall -wall -vall -p 21362

値 21362 は、応答しない ldapfwd プロセスの PID に対応します。

ハングアップに関するデータの分析

Directory Proxy Server がクラッシュする際には、常にコアが生成されます。このコアファイルおよびそのプロセススタックを使って、問題を分析できます。コアファイルの分析については、「Solaris でのコアファイルの確認」を参照してください。ただし、ユーティリティーを ns-slapd バイナリディレクトリから実行するのではなく、から実行する必要があります。

たとえば、truss コマンドの出力がクラッシュ時にシステムコールが作成されていないことを示している場合は、パッシブハングアップであることがわかります。コアファイルおよび jstack または pstack の情報を確認することにより、処理を続行するためにロックが解除されるのを待っている複数のスレッドを特定できます。さまざまなツールの出力を比較することにより、問題の原因がデッドロックであることを推測できます。この情報を使用することで、Sun サポートは問題解決の支援を適時的確に行うことができます。

クラッシュした Directory Proxy Server プロセスのトラブルシューティング

コアファイルおよびクラッシュダンプは、プロセスまたはアプリケーションが異常終了したときに生成されます。これらのファイルを分析することが、問題の原因特定に役立ちます。

この節では、次の内容について説明します。

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

コアファイルを分析するため、Directory Proxy Server プロセスに関係付けられたすべてのライブラリおよびバイナリを取得します。サーバーがクラッシュしたときに Directory Proxy Server がコアファイルを生成できるように、システムを設定します。コアファイルの生成の詳細については、「コアファイルの生成」を参照してください。

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

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


# pkg_app pid core-file
注 –

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

Solaris での Directory Proxy Server 6.3 コアデータの分析

コアファイルを取得したあとで、このファイルに対して jstack および jpmap Java ツールを実行します。

次のように jstack ユーティリティーを実行します。


# jstack process-ID

次に、jstack ユーティリティーの出力例を示します。


# jstack 8393
Attaching to process ID 8393, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 1.5.0_03-b07
Thread t@1: (state = BLOCKED)

Thread t@42: (state = IN_NATIVE) 
 - sun.nio.ch.ServerSocketChannelImpl.accept0(java.io.FileDescriptor, \
java.io.FileDescriptor, java.net.InetSocketAddress[]) (Interpreted frame)
 - sun.nio.ch.ServerSocketChannelImpl.accept0(java.io.FileDescriptor, \
java.io.FileDescriptor, java.net.InetSocketAddress[]) (Interpreted frame)
 - sun.nio.ch.ServerSocketChannelImpl.accept() @bci=130, line=145 \
(Interpreted frame)
 - com.sun.directory.proxy.extensions.ExtendedTCPClientListener.run() \
@bci=267, line=190 (Interpreted frame)

Thread t@41: (state = IN_NATIVE)
 - sun.nio.ch.ServerSocketChannelImpl.accept0(java.io.FileDescriptor, \
java.io.FileDescriptor, java.net.InetSocketAddress[]) (Interpreted frame)
 - sun.nio.ch.ServerSocketChannelImpl.accept0(java.io.FileDescriptor, \
java.io.FileDescriptor, java.net.InetSocketAddress[]) (Interpreted frame)
 - sun.nio.ch.ServerSocketChannelImpl.accept() @bci=130, line=145 \
(Interpreted frame)
 - com.sun.directory.proxy.extensions.ExtendedTCPClientListener.run() \
@bci=267, line=190 (Interpreted frame)

Solaris での Directory Proxy Server 5.x コアデータの分析

コアファイルを取得したあとで、このファイルに対して pstack および pmap Solaris ユーティリティーを実行します。

次のように pstack ユーティリティーを実行します。


# pstack core-file > /tmp/pstack.txt

次に、pstack ユーティリティーの出力例を示します。


core '/var/core/core_dps-dr-zone1_ldapfwd_0_0_1156942096_3167' of 3167: ./ldapfwd 
-t /var/opt/mps/serverroot/dps-dps-dr-zone1/etc/tailor.txt
-----------------  lwp# 1 / thread# 1  --------------------
 fedc0b6c __pollsys (ffbff680, 2, ffbff610, 0, 0, 1770) + 8
 fed5cea8 poll     (ffbff680, 2, 1770, 10624c00, 0, 0) + 7c
 ff19c610 _pr_poll_with_poll (1770, ffbff680, 927c0, ffbff91c, 2, 1) + 42c
 00039504 __1cLCAI_LF_CmgrDrun6F_v_ (75, 115d74, 11202c, 2, 88c00, 116510) + 1a8
 00062070 ldapfwdMain (0, ffbffa84, c, 9952c, feb60740, feb60780) + 1c
 0002f968 _start   (0, 0, 0, 0, 0, 0) + 108
-----------------  lwp# 3 / thread# 3  --------------------
 fedc0b6c __pollsys (fea19b70, 3, fea19b00, 0, 0, 3e8) + 8
 fed5cea8 poll     (fea19b70, 3, 3e8, 10624c00, 0, 0) + 7c
 ff19c610 _pr_poll_with_poll (3e8, fea19b70, 186a0, fea19e8c, 3, 2) + 42c
 0005de38 __1cIidarPollEwait6MI_i_ (fea19e6c, 186a0, 16e360, 1, 0, 1) + 20
 000639ec __1cJHeartbeatJheartbeat6Fpv_1_ (158f40, 1, 14da70, faa36, 16e360, faa5d) + 114
 fedbfd9c _lwp_start (0, 0, 0, 0, 0, 0)
-----------------  lwp# 136734 / thread# 136734  --------------------
 fedbfe40 __lwp_park (0, 0, 116710, 0, 0, 1) + 14
 00076548 __1cMCAI_LF_MutexHacquire6M_v_ (116708, fd2bc, 0, 46, fea24800, 1000) + 34
 00076158 __1cPCAI_LF_RefCountGAddRef6M_v_ (116708, 156510, 2400, 26dc, 11667c, 800) + 24
 0006ddb0 __1cVCAI_LF_ReferralServer2t5B6MpnPCAI_LF_ConnPair_pnVCAI_LF_RequestMessage_pnNCAI_LF_Server
_ipcibbi_v_ (197198, fe7790d8, 1541c0, 156510, 185, 1565b8) + 50
 00046324 __1cPCAI_LF_ConnPairYstart_referral_operation6MipCpnNCAI_LF_Server_i_i_ (fe7790d8, 1, 1565b8
, 156510, 1, 197198) + 26c
 0004f2a0 __1cPCAI_LF_ConnPairLsend_result6MrnOCAI_LF_Message_rnVCAI_LF_RequestMessage__v_ (fe7790d8, 
156eb8, 1541c0, 2400, 0, 0) + 354
 00044758 __1cPCAI_LF_ConnPairOinner_activity6MpnOCAI_LF_Message__v_ (fe7790d8, 156eb8, 11202c, f4f27,
 fe7790f8, 1) + 114c
 00045c24 __1cPCAI_LF_ConnPairDrun6M_v_ (fe7797c8, 198383, 170c78, fe7790d8, fe779e54, fe779740) + 6cc
 00046cd0 CAI_LF_StartFunction (157500, 11202c, 1, 0, 46ab4, 1) + 21c
 fedbfd9c _lwp_start (0, 0, 0, 0, 0, 0)
-----------------  lwp# 136735 / thread# 136735  --------------------
 fedc0b6c __pollsys (fe9e8d98, 3, fe9e8d28, 0, 0, 1d4c0) + 8
 fed5cea8 poll     (fe9e8d98, 3, 1d4c0, 10624c00, 0, 0) + 7c
 ff19c610 _pr_poll_with_poll (1d4c0, fe9e8d98, b71b00, fe9e9e74, 3, 2) + 42c
 0005de38 __1cIidarPollEwait6MI_i_ (fe9e9e54, b71b00, 1, f4f27, fe9e90f8, 12d8d0) + 20
 00045cbc __1cPCAI_LF_ConnPairDrun6M_v_ (fe9e97c8, 17bb43, 130ff8, fe9e90d8, fe9e9e54, fe9e9740) + 764
 00046cd0 CAI_LF_StartFunction (157500, 11202c, 1, 0, 46ab4, 1) + 21c
 fedbfd9c _lwp_start (0, 0, 0, 0, 0, 0)
-----------------  lwp# 136738 / thread# 136738  --------------------
 fedc0b6c __pollsys (fe9a8d98, 3, fe9a8d28, 0, 0, 1d4c0) + 8
 fed5cea8 poll     (fe9a8d98, 3, 1d4c0, 10624c00, 0, 0) + 7c
 ff19c610 _pr_poll_with_poll (1d4c0, fe9a8d98, b71b00, fe9a9e74, 3, 2) + 42c
 0005de38 __1cIidarPollEwait6MI_i_ (fe9a9e54, b71b00, 1, f4f27, fe9a90f8, 0) + 20
 00045cbc __1cPCAI_LF_ConnPairDrun6M_v_ (fe9a97c8, 198123, 130fd8, fe9a90d8, fe9a9e54, fe9a9740) + 764
 00046cd0 CAI_LF_StartFunction (157500, 11202c, 1, 0, 46ab4, 1) + 21c
 fedbfd9c _lwp_start (0, 0, 0, 0, 0, 0)
-----------------  lwp# 136788 / thread# 136788  --------------------
 00197d68 ???????? (116708, 1, 156510, 0, 0, 1000)
 0006dee4 __1cVCAI_LF_ReferralServer2T6M_v_ (155780, 1000, fedecbc0, fea25c00, fe779780, 0) + 34
 000707c4 __SLIP.DELETER__A (155780, 1, 4, a6c, 1, 2400) + 4
 00046a94 CAI_LF_ReferralStartFunction (155780, fe6da000, 0, 0, 46a64, 1) + 30
 fedbfd9c _lwp_start (0, 0, 0, 0, 0, 0)

pstack コマンドの代わりに mdb または adb コマンドを使用してもコアのスタックを表示できます。mdb コマンドはモジュラーデバッガであり、adb コマンドは Solaris に含まれる汎用デバッガです。次のように 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 を含まないスレッドを検索して、スタックを分析します。

Solaris では、Solaris dbx シンボリックデバッガも使用できます。これは、http://sun.com/ から無料で入手可能な開発者用のツールです。dbx ツールを使用すると、シンボリックデバッグを実行できます。このツールには操作可能な変数が含まれます。次に、dbx デバッガの出力例を示します。


current thread: t@2482121
=>[1] 0x0(0x156138, 0x0, 0xff000000, 0xfedefad4, 0x2, 0x2), at 0xffffffffffffffff
  [2] CAI_LF_RefCount::Release(0x116708, 0x1, 0x156138, 0x0, 0x0, 0x1000), at 0x7629c
  [3] CAI_LF_ReferralServer::~CAI_LF_ReferralServer(0x241270, 0x1000, 0xfedecbc0, 0xfe097c00, 
0xfe8d9780, 0x0), at 0x6dee4
  [4] __SLIP.DELETER__A(0x241270, 0x1, 0x4, 0xa6c, 0x1, 0x2400), at 0x707c4
  [5] CAI_LF_ReferralStartFunction(0x241270, 0xfe81a000, 0x0, 0x0, 0x46a64, 0x1), at 0x46a94

Linux での Directory Proxy Server 5.x コアデータの分析

Linux では、Solaris の pstack ユーティリティーの代わりに lsstack または pstack コマンドを使用します。次のように lsstack コマンドを実行します。


# lsstack /tmp/core-file

GNU プロジェクトデバッガ gdb を使用して、クラッシュ時に何が起きたかを確認することもできます。次のようにデバッガを実行します。


# gdb ./ldapfwd /tmp/core-file

gdb ツールで使用可能な有用なコマンドの詳細については、gdb のマニュアルページを参照してください。

HP-UX での Directory Proxy Server 5.x コアデータの分析

HP-UX では、Linux の場合と同様、GNU プロジェクトデバッガを使用してクラッシュ時に何が起きたかを確認することもできます。次のようにデバッガを実行します。


# gdb ./ldapfwd /tmp/core-file

gdb ツールで使用可能な有用なコマンドの詳細については、gdb のマニュアルページを参照してください。

Windows での Directory Proxy Server 5.x コアデータの分析

Windows では、カーネルおよび NT デバッグ用の UI を提供する WinDbg デバッガを使用できます。このデバッガは、カーネルモードとユーザーモードの両方で動作可能です。Windows のクラッシュダンプファイルに対して、このデバッガを実行します。