test

Sun Java Enterprise System 2005Q4 インストールガイド(UNIX 版)

第 9 章 トラブルシューティング

この章では、Sun JavaTM Enterprise System (Java ES) のインストールとアンインストールに関する問題を解決するためのヒントを提供します。

この章で説明する内容は、次のとおりです。

トラブルシューティングの手法

ここでは、Java ES のインストールおよびアンインストール時に、問題の原因を分析して特定するための一般的なガイドラインを紹介します。

ここで説明する内容は、次のとおりです。

インストールログファイルの検証

インストールまたはアンインストール中に問題が発生した場合、次の logs ディレクトリ内の適切なログファイルを確認します。

Solaris OS の場合: /var/sadm/install/logs

Linux の場合: /var/opt/sun/install/logs

アンインストーラとインストーラのログファイル、および Java ES の設定ログとコンポーネントのログを調べることは、問題の原因の特定に役立ちます。たとえば、インストールログに記録されているパッケージと、アンインストールログに記録されているパッケージを比較することができます。

ほとんどのログには 2 つのバージョンがあります。

次の表は、ログファイルの形式を示しています。

表 9–1 Java ES ログファイル名の形式

ログに記録される内容 

ログファイル名の形式 

インストーラ: コンポーネント 

Java_Enterprise_System_install.Atimestamp

Java_Enterprise_System_install.Btimestamp

Java_Enterprise_System_Config_Log.id

アンインストーラ 

Java_Enterprise_System_uninstall.Atimestamp

Java_Enterprise_System_uninstall.Btimestamp

Java_Enterprise_System_Config_Log.id

インストールサマリー 

Java_Enterprise_System_Summary_Report_install. timestamp

JavaES_Config_log.timestamp

JavaES_PanelFlow_log.timestamp

JavaES_MasterLog_log.timestamp

Java_Enterprise_System_Summary_Report_ uninstall. timestamp

ログファイルをトラブルシューティングに使用するには、最初に発生した問題を特定します。それは、最初の問題が原因となって、次々と問題が引き起こされることがよくあるためです。

Procedureログファイルによるトラブルシューティング

ログファイルによって、次に示すような、次の手順を見極めるためのヒントが与えられることがあります。

手順

  1. インストールのサマリーファイルを参照します。 このファイルには、何がインストールされ、設定されているかについての概要が記載されています。

    問題が発生した場合は、どのコンポーネントが問題の原因であるかを確認します。複数の問題が発生している場合は、最初の問題を特定します。

  2. 詳細なログファイルを参照します。

    1. 最初に発生したエラーまたは警告を探して、解決を試みます。1 つのエラーを解決すると、関連性がないように見える後続の多数のエラーも解決することがよくあります。

    2. 問題の原因となっているコンポーネントまたはパッケージの名前を探します。

コンポーネントログファイルの検証

コンポーネントの起動時に問題が発生する場合は、ログファイルを調べます。多くのコンポーネントのログファイルの場所については、「コンポーネントのトラブルシューティングのためのヒント」を参照してください。

製品の依存関係の検証

多数のコンポーネントに、インストール時の相互依存関係があります。1 つのコンポーネントに影響を与える問題は、別のコンポーネントにも影響を与える可能性があります。まず、『Sun Java Enterprise System 2005Q4 インストール計画ガイド』で説明されている内容をよく理解してください。

コンポーネントの相互依存関係のほかに、一部のコンポーネントは Solaris パッケージがインストールされているかどうかにも依存しています。 パッケージがホストにインストールされていない場合、それが原因でインストールが失敗することがあります。詳細については、リリースノートの「ソフトウェア要件」の節を参照してください。

リソースと設定のチェック

次のホストレベルの問題は、インストール時に問題を引き起こす可能性があります。

インストール後の設定のチェック

コンポーネントの起動時に問題が発生する場合は、第 6 章「インストール後のコンポーネントの設定」に記述されている手順が正しく行われたか確認します。

配布メディアのチェック

DVD または CD からのインストールでは、メディアの汚れや損傷を調べます。ディスクに汚れがあると、インストール時に問題が発生する可能性があります。

Directory Server の接続性チェック

Directory Server に依存するコンポーネントをインストールする場合、次のいずれかの問題によって問題が発生する可能性があります。

Web Server のファイルおよびディレクトリの削除

編集済みの設定ファイルなど、カスタマイズされたファイルの上書きを防ぐために、そのファイルが格納されるディレクトリには Web Server をインストールできません。

Web Server を再インストールする場合、インストールディレクトリをチェックして、それが空であることを確認します。空ではない場合は、どこか別の場所にファイルをアーカイブしてからインストールを再試行します。

パスワードの確認

インストーラは、コンポーネントごとにパスワードの入力を求めます。複数のホストに複数のコンポーネントをインストールする場合、各ホストで正しいパスワードを入力することが重要です。

パスワードの問題を解決するには、いったんアンインストールしてから再インストールすることが必要となる場合があります。アンインストールに失敗した場合は、「アンインストール時に残されたファイルによるインストールの失敗」を参照してください。

コンポーネントのインストール状態の検証

コンポーネントをインストールしたものの問題があり、再インストールまたはアンインストールを実行できない場合は、Solaris の pkginfo コマンドまたは Linux の rpm コマンドを使用して、インストールしたパッケージを調べます。その結果を、『Sun Java Enterprise System 2005Q4 インストールリファレンス』の第 5 章「インストール可能なパッケージの一覧」に記載されている Java ES パッケージと比較します。追加情報については、「アンインストール時に残されたファイルによるインストールの失敗」を参照してください。

ヒント –

Solaris 9 と Solaris 10 では、prodreg ツールを使用することもできます。 このツールは、製品レジストリへのグラフィカルインタフェースを提供し、pkg ユーティリティーの代わりに、各コンポーネントおよびそのパッケージの両方への索引付けをします。prodreg を起動するには、コマンド行でこのコマンド名を入力します。詳細については、prodreg(1) のマニュアルページを参照してください。

管理者アクセスの確認

「アンインストーラ用の管理者アクセス権の付与」で説明されているように、アンインストール時に管理者アクセス権をアンインストーラに付与しなければならないことがあります。

インストールに関する問題

ここでは、インストール時に発生する可能性のある次の問題について説明します。

アンインストール時に残されたファイルによるインストールの失敗

アンインストール時にコンポーネントやパッケージが削除されずに残されることがあります。このような場合、Java ES を再インストールする前に、コンポーネントやパッケージを手動で削除する必要があります。この問題には、次のものが該当します。

Procedure部分的なインストールのクリーンアップ

手順

  1. 次のコマンドを使用して、一部だけがインストールされたパッケージがないかどうか調べます。

    Solaris OS の場合:


    pkginfo -p

    Linux の場合:


    rpm -qa |grep sun | xargs rpm -V

    コマンドの出力で、一部だけがインストールされたパッケージのリストが表示されます。『Sun Java Enterprise System 2005Q4 インストールリファレンス』の第 5 章「インストール可能なパッケージの一覧」を参照し、返されたパッケージ名に基づいてそれらのパッケージが属しているコンポーネントを調べます。

  2. コンポーネントまたはパッケージを削除します。

    • Solaris 9 または Solaris 10 では、prodreg というツールを使用します。

      prodreg ツールを使用すると、ホスト上のパッケージベースのコンポーネントを管理できます。各コンポーネントとそのパッケージについて、相互依存関係を含む完全な情報を参照できます。prodreg ツールを使用して、安全にコンポーネントをアンインストールし、パッケージを削除することができます。prodreg ツールでコンポーネントを削除すると、再インストールできるようになります。

      • Solaris 8 では、pkgrm コマンドを使用します。

        pkgrm コマンドを使用すると、コンポーネントはパッケージごとにまとめて削除されます。このコマンドによって、製品のレジストリが更新されることはありません。コマンド実行後の状況に応じて、アーカイブされた製品のレジストリファイルを復元することも、削除されたコンポーネントを参照しないように、手動で製品のレジストリファイルを編集することもできます。

        製品のレジストリファイルを編集するには、/var/sadm/install/productregistry ファイルを開きます。この XML ファイルには、各コンポーネントの説明があります。各コンポーネントの説明は、<compid\> タグで始まり、</compid\> タグで終わります。コンポーネントのエントリ全体を削除します。

      • Linux では、rpm -e コマンドを使用します。

        製品のレジストリファイルを編集するには、/var/opt/sun/install/productregistry ファイルを開きます。この XML ファイルには、各コンポーネントの説明があります。各コンポーネントの説明は、<compid\> タグで始まり、</compid\> タグで終わります。コンポーネントのエントリ全体を削除します。

  3. /opt、/etc/opt、および /var/opt ディレクトリをクリーンアップします。

  4. インストーラをもう一度実行します。

アンインストール後に製品レジストリに含まれる共有コンポーネントが削除されたためにインストールが失敗する

Java ES 2005Q4 リリースから、インストールが終了すると、製品レジストリファイル内に共有コンポーネントが登録されるようになっています。

Java ES アンインストーラは、選択可能なコンポーネントをシステムから削除しますが、共有コンポーネントは削除しません。アンインストールが終了しても、製品レジストリには共有コンポーネントのエントリが依然として含まれています。アンインストール後に Java ES の共有コンポーネントを手動で削除しても、それらのコンポーネントは製品レジストリからは削除されません。したがって、次回の Java ES 2005Q4 のインストールは失敗します。なぜなら、手動で削除された共有コンポーネントに対するエントリが製品レジストリ内には依然として存在するため、インストーラはそれらのコンポーネントが存在するものと仮定するからです。

ヒント –

Java ES の共有コンポーネントをシステムから手動で削除しないでください。

推奨される解決方法: 製品レジストリファイルから対応するエントリを削除するか、製品レジストリファイル自体を削除します。製品レジストリファイルからエントリを削除するとファイルが壊れる危険性があるため、製品レジストリの全体を削除することをお勧めします。これを行う前に、Java ES コンポーネント以外の製品が製品レジストリファイルを使用していないことを確認してください。

Linux の場合: Linux ではグラフィカル製品レジストリファイルに相当するものはありません。したがって、そのような rpm ファイルを間違って削除した場合、製品レジストリファイルを手動で編集する必要があります。

IBM WebSphere を Portal Server の Web コンテナとして設定できない

WebSphere を実行していない、または WebSphere のネイティブ設定と一致しない WebSphere 値を指定したことが原因として考えられます。この問題の解決には、次の 2 つの方法があります。

設定のチェック

1 つの方法は、WebSphere インスタンスの設定をチェックすることです。

ProcedureWebSphere 設定のチェック

手順

  1. WebSphere が実行されていることを確認します。

  2. 次のインストーラフィールドの値を調べます。

    • WebSphere 仮想ホスト (状態ファイルの PS_IBM_VIRTUAL_HOST)

    • Application Server 名 (状態ファイルの PS_IBM_APPSERV_NAME)

  3. WebSphere ツールで設定をチェックし、これらの値と一致する値を確実に入力します。

  4. 再試行します。

新しいインスタンスの作成

もう 1 つの方法は、WebSphere エンティティーの新しいインスタンスを作成することです。

ProcedureWebSphere エンティティーの新しいインスタンスの作成

手順

  1. adminclient.sh を使用して、WebSphere コンソールを起動します。

  2. 新しい仮想ホストのインスタンスおよび新しい Application Server のインスタンス名を作成します。

  3. ノード (通常はホスト名) の下のエントリをクリックし、Regen WebServer Plugin を選択します。

    このプロセスにより、plugin 設定ファイルに新しいエントリが保存されます。インストーラによって、その正式名称がチェックされます。

  4. インストーラに戻り、作成した値を入力します。

予期せぬ外部エラーが発生する

電源障害またはシステム障害が発生した可能性があります。または CTRL/C を入力して、インストーラのプロセスを停止した可能性もあります。

推奨される解決方法: インストール中または設定プロセスで障害が発生した場合は、おそらく一部だけがインストールされたままになっています。インストーラを実行します。アンインストーラが失敗した場合は、「アンインストールが失敗し、ファイルが削除されずに残った」の手順に従います。

グラフィカルインストーラが応答しない

イメージが入力を受け付けるようになる前に、インストーラによって画面上にイメージが作成されることがあります。待ちきれずにインストールウィザードで何度も「次へ」をクリックすることは避けてください。

推奨される解決方法: デフォルトの選択肢を表すボタンには、青い四角形が表示されます。この四角形は、ボタンが表示されたあとに表示されることがあります。ボタンをクリックするときは、青い四角形が表示されるまで待ってください。

サイレントインストールの失敗: 状態ファイルに互換性がない、または破損している

使用しているプラットフォームで作成された状態ファイルを使用している場合、ファイルが壊れ、原因不明であるというエラーが発生する可能性があります。この問題の解決には、次の 2 つの方法があります。

新しい状態ファイルの生成

プラットフォームに適した新規 ID の作成

状態ファイルを作成したプラットフォームが、サイレントインストールを実行しているプラットフォームと異なる場合、状態ファイルに対してプラットフォームに適した ID を新たに作成します。この方法については、「プラットフォームに適した状態ファイル ID の作成」を参照してください。

サイレントインストールに失敗した

状態ファイルを編集した場合、それによってエラーが発生した可能性があります。次の点をチェックし、「状態ファイルの作成」の説明に従って状態ファイルを再生成します。

マニュアルページが表示されない

この問題が起きる場合、たいていはインストールしたコンポーネントの MANPATH 環境変数が正しく設定されていないことが原因です。「MANPATH の設定」を参照してください。

アンインストールに関する問題

ここでは、アンインストール時に発生する可能性のある次の問題について説明します。

アンインストーラが見つからない

Java ES のインストールプログラムは、システム上の次の場所に uninstall (アンインストーラ) を格納します。

アンインストーラがこのディレクトリにない場合は、次のいずれかの原因が考えられます。

推奨される解決方法: 「アンインストールが失敗し、ファイルが削除されずに残った」の説明に従ってシステムを手動でクリーンアップします。

アンインストールが失敗し、ファイルが削除されずに残った

アンインストーラがファイルまたはプロセスを削除できなかったために手動クリーンアップが必要となった場合は、次の手順を実行し、システムからパッケージを削除します。

Procedure手動でのパッケージのクリーンアップ

手順

  1. 削除が必要なパッケージを特定します。

    システム上のパッケージを、『Sun Java Enterprise System 2005Q4 インストールリファレンス』の第 5 章「インストール可能なパッケージの一覧」に記載されている Java ES パッケージと比較します。インストールされているパッケージを特定するには、Solaris の pkginfo または prodreg ユーティリティー、あるいは Linux の rpm コマンドを使用できます。(「アンインストール時に残されたファイルによるインストールの失敗」を参照)

  2. Java ES コンポーネントの実行中のプロセスをすべて停止します。

    プロセスの停止手順の概要については、第 6 章「インストール後のコンポーネントの設定」のコンポーネントマニュアルを参照してください。

  3. 以後のインストールで再利用を考えているカスタム設定データとユーザーデータをすべてバックアップします。

    バックアップすべき設定データやユーザーデータについては、「Java ES コンポーネントのアンインストール動作の確認」を参照してください。詳細については、各コンポーネントのマニュアルを参照してください。

  4. pkgrm または rpm -e コマンドを使って Java ES コンポーネントパッケージを削除します。

  5. 以後のインストールで使用しない、残されているコンポーネントディレクトリとその内容をすべて削除します。これらのディレクトリをあとで利用する場合は、別の場所に移動します。

  6. 次の場所にある製品レジストリファイルを更新します。

    Solaris OS の場合: /var/sadm/install/productregistry

    Linux の場合: /var/opt/sun/install/productregistry

    アンインストーラはこのレジストリを使用して、ホストにインストールされているコンポーネントを特定します。インストーラとアンインストーラは、インストールまたはアンインストールの完了時に製品レジストリを更新します。

    注 –

    アンインストーラを使用せずに、パッケージを手動で削除した場合は、システムにインストールされているソフトウェアを製品レジストリが正しく反映するように、このファイルを手動で更新する必要があります。

  7. 次の場所にあるシステムのログファイルをクリーンアップします。

    Solaris OS の場合: /var/sadm/install/logs

    Linux の場合: /var/opt/sun/install/logs

    ログファイルは、パッケージを手動削除したあとのシステムの状態を正しく反映していない可能性があります。

製品レジストリが破損している

アンインストール時に、アンインストーラは製品レジストリファイルを使用して、アンインストールが必要な要素を特定します。

Solaris OS の場合: /var/sadm/install/productregistry

Linux の場合: /var/opt/sun/install/productregistry

Common Agent Container の問題

ここでは、Common Agent Container の共有コンポーネントに関連して起きる可能性のある次の問題について説明します。

ポート番号の競合

Java ES 内部の Common Agent Container は、デフォルトで次のポート番号を占有します。

上記のポート番号のいずれかがすでにインストール時に予約されている場合は、Common Agent Container が占有するポート番号を次のようにして変更します。

Common Agent Container の cacaoadm コマンドの詳細については、cacaoadm のマニュアルページを参照してください。このマニュアルページをコマンド行に表示できない場合は、MANPATH が正しく設定されているか確認します。「MANPATH の設定」を参照してください。

ポート番号の確認

ProcedureSolaris のポートの確認

手順

  1. ルートとして、Common Agent Container 管理デーモンを停止します。


    # /opt/SUNWcacao/bin/cacaoadm stop

  2. 次の構文を使用して、ポート番号を変更します。


    # /opt/SUNWcacao/bin/cacaoadm set-param param=value

    たとえば、SNMP アダプタが占有するポートをデフォルトの 10161 から 10165 に変更するには、次のようにします。


    # /opt/SUNWcacao/bin/cacaoadm set-param snmp-adaptor-port=10165

  3. Common Agent Container 管理デーモンを再起動します。


    # /opt/SUNWcacao/bin/cacaoadm start

ProcedureLinux のポートの確認

手順

  1. ルートとして、Common Agent Container 管理デーモンを停止します。


    # /opt/sun/cacao/bin/cacaoadm stop

  2. 次の構文を使用して、ポート番号を変更します。


    # /opt/sun/cacao/bin/cacaoadm set-param param=value

    たとえば、SNMP アダプタが占有するポートを 10161 から 10165 に変更するには、次のようにします。


    # /opt/sun/cacao/bin/cacaoadm set-param snmp-adaptor-port=10165

  3. Common Agent Container 管理デーモンを再起動します。


    # /opt/sun/cacao/bin/cacaoadm start

ルートパスワードの安全性が危惧される場合

Java ES が稼働するホストで、セキュリティーキーを再生成することが必要になる場合があります。たとえば、ルートパスワードが他の人に知られたおそれがあり、安全性が危うくなっている場合には、セキュリティーキーを再生成することが必要です。Common Agent Container サービスによって使用されるキーは、次の場所に格納されています。

Solaris OS の場合: /etc/opt/SUNWcacao/security

Linux の場合: /etc/opt/sun/cacao/security

通常の操作条件では、これらのキーはデフォルトの設定のままでかまいません。キーの安全性が危うくなったために、キーを再生成することが必要な場合は、次の手順でセキュリティーキーを再生成できます。

セキュリティーキーの問題

ProcedureSolaris OS の場合のキー生成

手順

  1. ルートとして、Common Agent Container 管理デーモンを停止します。


    # /opt/SUNWcacao/bin/cacaoadm stop

  2. セキュリティーキーを再生成します。


    # /opt/SUNWcacao/bin/cacaoadm create-keys --force

  3. Common Agent Container 管理デーモンを再起動します。


    # /opt/SUNWcacao/bin/cacaoadm start
    注 –

    Sun Cluster ソフトウェアの場合は、この変更をクラスタ内のすべてのノードに伝達する必要があります。詳細については、『Sun Cluster Software Installation Guide for Solaris OS』の「How to Finish a Rolling Upgrade to Sun Cluster 3.1 8/05 Software」を参照してください。

ProcedureLinux の場合のキー生成

手順

  1. ルートとして、Common Agent Container 管理デーモンを停止します。


    # /opt/sun/cacao/bin/cacaoadm stop

  2. セキュリティーキーを再生成します。


    # /opt/sun/cacao/bin/cacaoadm create-keys --force

  3. Common Agent Container 管理デーモンを再起動します。


    # /opt/sun/cacao/bin/cacaoadm start

    cacaoadm コマンドの詳細については、cacaoadm(1M) のマニュアルページを参照してください。

ロックファイルに関するエラー通知

cacaoadm サブコマンドを実行したところ、別のユーザーがまったく同時に何かのコマンドを実行しているということもありえます。しかし、cacaoadm サブコマンドは一度に 1 つしか実行できません。

Solaris OS の場合、次のエラーメッセージが生成されます。

If cacaoadm daemon is running, it is busy executing another command.
Otherwise remove lock file /var/opt/SUNWcacao/run/lock

Linux の場合、次のエラーメッセージが生成されます。

If cacaoadm daemon is running, it is busy executing another command.
Otherwise remove lock file /var/opt/sun/cacao/run/lock.

この通知メッセージを受け取ったときにまず行うとよいことは、少し待ってから再試行することです。

再試行しても同じ通知メッセージを受け取るときには、ロックファイルが Common Agent Container 管理デーモンによって削除されていない可能性があります。障害発生時にそのようになることがあります。ロックファイルがあるために、それ以後 cacaoadm サブコマンドは実行できません。

エラーメッセージに示されている場所からロックファイルを削除します。

コンポーネントのトラブルシューティングのためのヒント

ここでは、コンポーネントについてのさまざまなヒントを提供し、役立つマニュアルを紹介します。

ここで説明する内容は、次のとおりです。

Access Manager のトラブルシューティングのヒント

表 9–2 Access Manager のトラブルシューティングのヒント

項目 

詳細 

設定ファイル

AMConfig.properties

Solaris OS の場合: /etc/opt/SUNWam/config

Linux の場合: /etc/opt/sun/identity/config

ログファイルとデバッグファイル

ログファイルのディレクトリ: 

  • Solaris OS の場合: /var/opt/SUNWam/logs

  • Linux の場合: /var/opt/sun/identity/logs

    デバッグファイルのディレクトリ:

  • Solaris OS の場合: /var/opt/SUNWam/debug

  • Linux の場合: /var/opt/sun/identity/debug

デバッグモード

『Sun Java System Access Manager 7 2005Q4 Developer’s Guide』の「Auditing Features」の章を参照してください。

管理サーバーのトラブルシューティングのヒント

表 9–3 管理サーバーのトラブルシューティングのヒント

項目 

詳細 

ログファイル

インストールログのディレクトリ:

トラブルシューティング

を参照してください。 

Application Server のトラブルシューティングのヒント

表 9–4 Application Server のトラブルシューティングのヒント

項目 

詳細 

ログファイル

ログファイルのディレクトリ: 

Solaris OS の場合: /var/sadm/install/logs/

Linux の場合: /var/opt/sun/install/logs/

Application Server インスタンスのログディレクトリ (最初に作成するインスタンスのデフォルトの場所): 

Solaris OS の場合: /var/opt/SUNWappserver/domains/domain1/logs

Linux の場合: /var/opt/sun/appserver/domains/domain1/logs

メッセージログのファイル名: 

server.log (サーバーインスタンスごとに存在する)

設定ファイル

設定ファイルのディレクトリ: /var

トラブルシューティング

『Sun Java System Application Server Enterprise Edition 8.1 2005Q2 Troubleshooting Guide』を参照してください。

Calendar Server のトラブルシューティングのヒント

表 9–5 Calendar Server のトラブルシューティングのヒント

項目 

詳細 

ログファイル

管理サービス (csadmind): admin.log分散

データベースサービス (csdwpd): dwp.logHTTP サービス (cshttpd): http.log

通知サービス (csnotifyd): notify.logCalendar

バックアップサービス (csstored): store.log

デフォルトのログディレクトリ: /var/opt/SUNWics5/logs

詳細については、『Sun Java System Calendar Server 6 2005Q4 Administration Guide』を参照してください。

設定ファイル

/opt/SUNWics5/cal/config/ics.conf

デバッグモード

デバッグモードを使用するには、Calendar Server の管理者が ics.conf ファイルで logfile.loglevel 設定パラメータを設定します。次に例を示します。

logfile.loglevel = "debug"

詳細については、『Sun Java System Calendar Server 6 2005Q4 Administration Guide』を参照してください。

トラブルシューティング

『Sun Java System Calendar Server 6 2005Q4 Administration Guide』を参照してください。

Communications Express のトラブルシューティングのヒント

表 9–6 Communications Express のトラブルシューティングのヒント

項目 

詳細 

ログファイル

デフォルトのログファイル: uwc-deployed-path/logs/uwc.log

トラブルシューティング

『Sun Java System Communications Express 6 2005Q4 Administration Guide』の第 5 章「Troubleshooting」を参照してください。

Delegated Administrator のトラブルシューティングのヒント

表 9–7 Delegated Administrator のトラブルシューティングのヒント

項目 

詳細 

ログファイル

実行時ログファイル: /opt/SUNWcomm/log

トラブルシューティング

『Sun Java System Communications Services 6 2005Q4 Delegated Administrator Guide』の付録 C「Debugging Delegated Administrator」を参照してください。

Directory Proxy Server のトラブルシューティングのヒント

表 9–8 Directory Proxy Server のトラブルシューティングのヒント

項目 

詳細 

ログファイル

デフォルトのログファイル: DirectoryProxyServer-base /dps -hostname/logs/fwd.log

詳細については、『Sun Java System Directory Proxy Server 5 2005Q1 Administration Guide』を参照してください。

トラブルシューティング

『Sun Java System Directory Proxy Server 5 2005Q1 Administration Guide』を参照してください。

Directory Server のトラブルシューティングのヒント

表 9–9 Directory Server のトラブルシューティングのヒント

項目 

詳細 

ログファイル

インストールログファイル: 

Solaris OS の場合: /var/sadm/install/logs

Linux の場合: /var/opt/sun/install/logs

設定ログファイル: 

Directory_Server_install.Atimestamp

Directory_Server_install.Btimestamp

ログファイルの管理については、『Sun Java System Directory Server 5 2005Q1 Administration Guide』を参照してください。

トラブルシューティング

『Sun Java System Directory Server 5 2005Q1 Administration Guide』を参照してください。

Instant Messaging のトラブルシューティングのヒント

Instant Messaging のトラブルシューティングについては、クライアントのオンラインヘルプおよび『Sun Java System Instant Messaging 7 2005Q1 Administration Guide』を参照してください。

Message Queue のトラブルシューティングのヒント

表 9–10 Message Queue のトラブルシューティングのヒント

項目 

詳細 

トラブルシューティング

『Sun Java System Message Queue 管理ガイド』の「問題のトラブルシューティング」の章、および次の MQ フォーラムを参照してください。http://swforum.sun.com/jive/forum.jspa?forumID=24

パフォーマンス

『Sun Java System Message Queue 3 2005Q4 管理ガイド』の「メッセージサービスの分析と調整」を参照してください。

Messaging Server のトラブルシューティングのヒント

表 9–11 Messaging Server のトラブルシューティングのヒント

項目 

詳細 

実行ファイルの場所

/opt/SUNWmsgsr/sbin

ログファイル

MessagingServer-base/data/log

トラブルシューティング

『Sun Java System Messaging Server 6 2005Q4 Administration Guide』を参照してください。

Portal Server のトラブルシューティングのヒント

Portal Server は、Access Manager と同じログファイルとデバッグファイルを使用します。

表 9–12 Portal Server のトラブルシューティングのヒント

項目 

詳細 

デバッグファイル

Solaris OS の場合: /var/opt/SUNWam/debug

Linux の場合: /var/opt/sun/identity/debug

ログファイル

Solaris OS の場合: /var/opt/SUNWam/logs

Linux の場合: /var/opt/sun/identity/logs

トラブルシューティング

『Sun Java System Portal Server 6 2005Q4 管理ガイド』を参照してください。

Portal Server は、Access Manager と同じログファイルとデバッグファイルを使用します。

ヒント –

dpadmin、par、rdmgr、および sendrdm という Portal Server コマンド行ユーティリティーには、デバッグメッセージを生成するためのオプションがあります。それらのオプションについては、『Portal Server 管理ガイド』を参照してください。

Portal Server Secure Remote Access のトラブルシューティングのヒント

Portal Gateway のデバッグログは次のディレクトリに格納されます。

注 –

Access Manager 管理コンソールからロギングをオンにした場合、NetFile などの Portal Server サービスのログは /var/opt/SUNWam/debug に作成されます。

Service Registry のトラブルシューティングのヒント

表 9–13 Service Registry のトラブルシューティングのヒント

項目 

詳細 

ログファイル

Application Server のインスタンスログ:  

Solaris OS の場合: /var/opt/SUNWsoar/domains/registry/logs/server.log

Linux の場合: /var/opt/sun/SUNWsoar/domains/registry/logs/server.log

トラブルシューティング

『Service Registry 3 2005Q4 Administration Guide』を参照してください。

Sun Cluster ソフトウェアのトラブルシューティングのヒント

表 9–14 Sun Cluster ソフトウェアのトラブルシューティングのヒント

項目 

詳細 

ログファイル

デフォルトのログディレクトリ: /var/cluster/logs/install

エラーメッセージ: /var/adm/messages

トラブルシューティング

『Sun Cluster Software Installation Guide for Solaris OS』を参照してください。

Web Server のトラブルシューティングのヒント

表 9–15 Web Server のトラブルシューティングのヒント

項目 

詳細 

ログファイル

Web Server のログファイルは 2 種類あります。errors ログファイルと access ログファイルです。どちらも次のディレクトリに格納されます。

  • Solaris OS の場合: /opt/SUNWwbsvr/https- instancename/logs

  • Linux の場合: /opt/sun/webserver/https-instancename /logs

errors ログファイルには、サーバーで発生したすべてのエラーがリストされます。access ログファイルには、サーバーに対する要求と、サーバーからの応答に関する情報が記録されます。詳細については、『Sun Java System Web Server 6.1 SP4 Administrator’s Guide』を参照してください。

トラブルシューティング

『Sun Java System Web Server 6.1 SP4 Installation and Migration Guide』を参照してください。

設定ファイルのディレクトリ

/opt/SUNWwbsvr/https-instance-name /config

デバッグモード

次のオプションを使用できます。 

  • ログ出力は、診断とデバッグに利用できる可能性があります。/server_root/https-instancename/config/server.xml ファイル内の LOG 要素の loglevel 属性の値を、次の値に設定できます。info、fine、finer、または finest。これらの値は、デバッグメッセージの詳細度を示し、finest で詳細度が最大になります。LOG 要素の詳細については、『Sun Java System Web Server 6.1 SP4 Administrator’s Configuration File Reference』を参照してください。

  • デバッグフラグを有効化してサーバーの Web コンテナをデバッグモードで起動し、JPDA (Java Platform Debugger Architecture) デバッガとの連携準備を整えることができます。これを行うには、/instance_root/https-servername/config/server.xml ファイル内の JAVA 属性の jvm.debug フラグの値を、true に設定します。詳細については、『Sun Java System Web Server 6.1 SP4 Administrator’s Configuration File Reference』を参照してください。

  • Sun Java System Studio 5, Standard Edition のプラグインは、Web アプリケーションのデバッグに利用できます。詳細については、『Sun Java System Web Server 6.1 SP4 Programmer’s Guide to Web Applications』を参照してください。

Web Proxy Server のトラブルシューティングのヒント

表 9–16 Web Proxy Server のトラブルシューティングのヒント

項目 

詳細 

ログファイル

デフォルトのログの場所: /opt/SUNWproxy/ proxy-instancename/logs

詳細については、『Sun Java System Web Proxy Server 4.0.2 2005Q4 Administration Guide』を参照してください。

設定ファイルのディレクトリ

/opt/SUNWproxy/proxy-instancename /config

デバッグモード

/server-root/proxy-instance-name/config/server.xml ファイル内の LOG 要素の loglevel 属性の値を、次の値に設定できます。info、fine、finer、finest。

トラブルシューティングの追加情報

このマニュアルに記載されている次の情報も、トラブルシューティングに役立ちます。