この章では、Sun JavaTM Enterprise System (Java ES) のインストールとアンインストールに関する問題を解決するためのヒントを提供します。
この章で説明する内容は、次のとおりです。
ここでは、Java ES のインストールおよびアンインストール時に、問題の原因を分析して特定するための一般的なガイドラインを紹介します。
ここで説明する内容は、次のとおりです。
インストールまたはアンインストール中に問題が発生した場合、次の logs ディレクトリ内の適切なログファイルを確認します。
Solaris OS の場合: /var/sadm/install/logs
Linux の場合: /var/opt/sun/install/logs
アンインストーラとインストーラのログファイル、および Java ES の設定ログとコンポーネントのログを調べることは、問題の原因の特定に役立ちます。たとえば、インストールログに記録されているパッケージと、アンインストールログに記録されているパッケージを比較することができます。
ほとんどのログには 2 つのバージョンがあります。
ログファイルの A バージョンには完了が記録されます。
ログ ファイルの B バージョンには、詳細なログメッセージが保存されます。
次の表は、ログファイルの形式を示しています。
表 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 |
ログファイルをトラブルシューティングに使用するには、最初に発生した問題を特定します。それは、最初の問題が原因となって、次々と問題が引き起こされることがよくあるためです。
ログファイルによって、次に示すような、次の手順を見極めるためのヒントが与えられることがあります。
設定に問題がある場合は、設定のサマリーを参照して使用している設定を調べます。
ディレクトリが競合している場合は、コンポーネントによって予約されているディレクトリを指定していないかどうかチェックします。
インストールのサマリーファイルを参照します。 このファイルには、何がインストールされ、設定されているかについての概要が記載されています。
問題が発生した場合は、どのコンポーネントが問題の原因であるかを確認します。複数の問題が発生している場合は、最初の問題を特定します。
詳細なログファイルを参照します。
コンポーネントの起動時に問題が発生する場合は、ログファイルを調べます。多くのコンポーネントのログファイルの場所については、「コンポーネントのトラブルシューティングのためのヒント」を参照してください。
多数のコンポーネントに、インストール時の相互依存関係があります。1 つのコンポーネントに影響を与える問題は、別のコンポーネントにも影響を与える可能性があります。まず、『Sun Java Enterprise System 2005Q4 インストール計画ガイド』で説明されている内容をよく理解してください。
サマリーファイルおよびログファイルを参照し、関連付けられている製品に問題が発生していないかどうか確認します。これにより、最初に解決すべきことの手がかりが得られる可能性があります。
正しい接続情報を指定しているかどうかチェックします。例:
Directory Server の設定時に指定した情報は、Directory Server を使用するコンポーネントに指定したディレクトリ情報と一致しているか。
Portal Server または Portal Server SRA に指定した Access Manager の情報は、Access Manager に指定した情報と一致しているか。
コンポーネントの相互依存関係のほかに、一部のコンポーネントは Solaris パッケージがインストールされているかどうかにも依存しています。 パッケージがホストにインストールされていない場合、それが原因でインストールが失敗することがあります。詳細については、リリースノートの「ソフトウェア要件」の節を参照してください。
次のホストレベルの問題は、インストール時に問題を引き起こす可能性があります。
アップデート: 推奨アップデート (パッチ) は適用されているか。
ディスク容量: ディスクパーティションをどのように設定し、どのパーティションにインストールディレクトリを作成するか。インストールディレクトリ /var/sadm および /etc/opt、または独自に指定したデフォルト以外のディレクトリに、十分なディスクの空き容量が必要です。
ネットワークポート: 設定時に、Java ES コンポーネントのポート番号を指定します。次の項目をチェックします。
/etc/services ファイルで標準ポート番号を調べる。
サマリーログファイルを参照し、標準の設定と比較する。ポート番号を誤って入力していないか、またはあるサーバーに対して通常は別のサーバーで使用するポートを設定していないか。
netstat -a コマンドを使用して、現在システムで使用しているポートを調べる。すでに他で使用中のポート番号を割り当てていないか。
IP アドレス: 設定時に、IP アドレスを指定します。正しい IP アドレスを入力したかどうかチェックします。確認する必要のあることがいくつかあります。
このシステムに複数のネットワークインタフェースがある場合、それぞれに独自の IP アドレスが指定されているか。
高可用性設定において、論理ホストの IP アドレス、またはクラスタノードの IP アドレスを指定したか。
コンポーネントの起動時に問題が発生する場合は、第 6 章「インストール後のコンポーネントの設定」に記述されている手順が正しく行われたか確認します。
DVD または CD からのインストールでは、メディアの汚れや損傷を調べます。ディスクに汚れがあると、インストール時に問題が発生する可能性があります。
Directory Server に依存するコンポーネントをインストールする場合、次のいずれかの問題によって問題が発生する可能性があります。
Directory Server に対して不正なユーザー ID およびパスワードを指定した。
不正な LDAP ポートを指定した。
Directory Server に接続できない。
インストーラを対話モードで実行するとインストール時に Directory Server の接続性がチェックされますが、サイレントモードではチェックされません。Directory Server を利用できない状態でサイレントインストールを実行すると、Access Manager または Portal 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 を再インストールする前に、コンポーネントやパッケージを手動で削除する必要があります。この問題には、次のものが該当します。
アンインストーラで問題が発生し、アンインストールに失敗したパッケージの名前が表示される。
一度削除したコンポーネントをインストールしようとしたが、インストーラはそのコンポーネントがすでにインストールされていることを示す。
次のコマンドを使用して、一部だけがインストールされたパッケージがないかどうか調べます。
Solaris OS の場合:
pkginfo -p |
Linux の場合:
rpm -qa |grep sun | xargs rpm -V |
コマンドの出力で、一部だけがインストールされたパッケージのリストが表示されます。『Sun Java Enterprise System 2005Q4 インストールリファレンス』の第 5 章「インストール可能なパッケージの一覧」を参照し、返されたパッケージ名に基づいてそれらのパッケージが属しているコンポーネントを調べます。
コンポーネントまたはパッケージを削除します。
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\> タグで終わります。コンポーネントのエントリ全体を削除します。
/opt、/etc/opt、および /var/opt ディレクトリをクリーンアップします。
インストーラをもう一度実行します。
Java ES 2005Q4 リリースから、インストールが終了すると、製品レジストリファイル内に共有コンポーネントが登録されるようになっています。
Java ES アンインストーラは、選択可能なコンポーネントをシステムから削除しますが、共有コンポーネントは削除しません。アンインストールが終了しても、製品レジストリには共有コンポーネントのエントリが依然として含まれています。アンインストール後に Java ES の共有コンポーネントを手動で削除しても、それらのコンポーネントは製品レジストリからは削除されません。したがって、次回の Java ES 2005Q4 のインストールは失敗します。なぜなら、手動で削除された共有コンポーネントに対するエントリが製品レジストリ内には依然として存在するため、インストーラはそれらのコンポーネントが存在するものと仮定するからです。
Java ES の共有コンポーネントをシステムから手動で削除しないでください。
推奨される解決方法: 製品レジストリファイルから対応するエントリを削除するか、製品レジストリファイル自体を削除します。製品レジストリファイルからエントリを削除するとファイルが壊れる危険性があるため、製品レジストリの全体を削除することをお勧めします。これを行う前に、Java ES コンポーネント以外の製品が製品レジストリファイルを使用していないことを確認してください。
Linux の場合: Linux ではグラフィカル製品レジストリファイルに相当するものはありません。したがって、そのような rpm ファイルを間違って削除した場合、製品レジストリファイルを手動で編集する必要があります。
WebSphere を実行していない、または WebSphere のネイティブ設定と一致しない WebSphere 値を指定したことが原因として考えられます。この問題の解決には、次の 2 つの方法があります。
1 つの方法は、WebSphere インスタンスの設定をチェックすることです。
WebSphere が実行されていることを確認します。
次のインストーラフィールドの値を調べます。
WebSphere 仮想ホスト (状態ファイルの PS_IBM_VIRTUAL_HOST)
Application Server 名 (状態ファイルの PS_IBM_APPSERV_NAME)
WebSphere ツールで設定をチェックし、これらの値と一致する値を確実に入力します。
再試行します。
もう 1 つの方法は、WebSphere エンティティーの新しいインスタンスを作成することです。
adminclient.sh を使用して、WebSphere コンソールを起動します。
新しい仮想ホストのインスタンスおよび新しい Application Server のインスタンス名を作成します。
ノード (通常はホスト名) の下のエントリをクリックし、Regen WebServer Plugin を選択します。
このプロセスにより、plugin 設定ファイルに新しいエントリが保存されます。インストーラによって、その正式名称がチェックされます。
インストーラに戻り、作成した値を入力します。
電源障害またはシステム障害が発生した可能性があります。または CTRL/C を入力して、インストーラのプロセスを停止した可能性もあります。
推奨される解決方法: インストール中または設定プロセスで障害が発生した場合は、おそらく一部だけがインストールされたままになっています。インストーラを実行します。アンインストーラが失敗した場合は、「アンインストールが失敗し、ファイルが削除されずに残った」の手順に従います。
イメージが入力を受け付けるようになる前に、インストーラによって画面上にイメージが作成されることがあります。待ちきれずにインストールウィザードで何度も「次へ」をクリックすることは避けてください。
推奨される解決方法: デフォルトの選択肢を表すボタンには、青い四角形が表示されます。この四角形は、ボタンが表示されたあとに表示されることがあります。ボタンをクリックするときは、青い四角形が表示されるまで待ってください。
使用しているプラットフォームで作成された状態ファイルを使用している場合、ファイルが壊れ、原因不明であるというエラーが発生する可能性があります。この問題の解決には、次の 2 つの方法があります。
サイレントインストールを実行しているのと同じプラットフォームで状態ファイルを作成した場合は、新しい状態ファイルを生成して再インストールします。
別のプラットフォームまたは別のバージョンで作成した状態ファイルを使用している場合、問題は、その状態ファイルが、作成したときと同じタイプのプラットフォームだけで実行できることです。たとえば、状態ファイルを Solaris 9 で作成した場合、そのファイルは Solaris 8 では使用できません。 また、x86 プラットフォームで作成した状態ファイルは、SPARC プラットフォームでは使用できません。
状態ファイルを作成したプラットフォームが、サイレントインストールを実行しているプラットフォームと異なる場合、状態ファイルに対してプラットフォームに適した ID を新たに作成します。この方法については、「プラットフォームに適した状態ファイル ID の作成」を参照してください。
状態ファイルを編集した場合、それによってエラーが発生した可能性があります。次の点をチェックし、「状態ファイルの作成」の説明に従って状態ファイルを再生成します。
すべてのローカルホストパラメータが設定され、矛盾のない値が設定されているか。
パラメータ値の大文字、小文字の区別は適切か。
目的のパラメータを入力せずに、必須のパラメータを削除してしまっていないか。
使用するすべてのポート番号は有効であり、かつ割り当て済みではないか。
この問題が起きる場合、たいていはインストールしたコンポーネントの MANPATH 環境変数が正しく設定されていないことが原因です。「MANPATH の設定」を参照してください。
ここでは、アンインストール時に発生する可能性のある次の問題について説明します。
Java ES のインストールプログラムは、システム上の次の場所に uninstall (アンインストーラ) を格納します。
Solaris OS の場合: /var/sadm/prod/SUNWentsys4
Linux の場合: /var/sadm/prod/sun-entsys4
アンインストーラがこのディレクトリにない場合は、次のいずれかの原因が考えられます。
このホストに Java ES がインストールされたことが一度もない
Java ES アンインストーラは、すでにアンインストーラを含むすべてのコンポーネントをこのホストから削除している。
アンインストール時に、どの Java ES コンポーネントもホストに存在しないことを検出すると、アンインストーラはアンインストーラ自身をもアンインストールします。
失敗したインストールの実行中に、次のいずれかの状況が生じた。
アンインストーラがホストにインストールされなかった。
アンインストーラは削除されたが、一部の Java ES コンポーネントはホストに残された。
推奨される解決方法: 「アンインストールが失敗し、ファイルが削除されずに残った」の説明に従ってシステムを手動でクリーンアップします。
アンインストーラがファイルまたはプロセスを削除できなかったために手動クリーンアップが必要となった場合は、次の手順を実行し、システムからパッケージを削除します。
削除が必要なパッケージを特定します。
システム上のパッケージを、『Sun Java Enterprise System 2005Q4 インストールリファレンス』の第 5 章「インストール可能なパッケージの一覧」に記載されている Java ES パッケージと比較します。インストールされているパッケージを特定するには、Solaris の pkginfo または prodreg ユーティリティー、あるいは Linux の rpm コマンドを使用できます。(「アンインストール時に残されたファイルによるインストールの失敗」を参照)
Java ES コンポーネントの実行中のプロセスをすべて停止します。
プロセスの停止手順の概要については、第 6 章「インストール後のコンポーネントの設定」のコンポーネントマニュアルを参照してください。
以後のインストールで再利用を考えているカスタム設定データとユーザーデータをすべてバックアップします。
バックアップすべき設定データやユーザーデータについては、「Java ES コンポーネントのアンインストール動作の確認」を参照してください。詳細については、各コンポーネントのマニュアルを参照してください。
pkgrm または rpm -e コマンドを使って Java ES コンポーネントパッケージを削除します。
以後のインストールで使用しない、残されているコンポーネントディレクトリとその内容をすべて削除します。これらのディレクトリをあとで利用する場合は、別の場所に移動します。
次の場所にある製品レジストリファイルを更新します。
Solaris OS の場合: /var/sadm/install/productregistry
Linux の場合: /var/opt/sun/install/productregistry
アンインストーラはこのレジストリを使用して、ホストにインストールされているコンポーネントを特定します。インストーラとアンインストーラは、インストールまたはアンインストールの完了時に製品レジストリを更新します。
アンインストーラを使用せずに、パッケージを手動で削除した場合は、システムにインストールされているソフトウェアを製品レジストリが正しく反映するように、このファイルを手動で更新する必要があります。
次の場所にあるシステムのログファイルをクリーンアップします。
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 の共有コンポーネントに関連して起きる可能性のある次の問題について説明します。
Java ES 内部の Common Agent Container は、デフォルトで次のポート番号を占有します。
JMX ポート (TCP) = 10162
SNMP アダプタポート (UDP) = 10161
トラップ用 SNMP アダプタポート (UDP) = 10162
Commandstream アダプタポート (TCP) = 10163
RMI コネクタポート (TCP) = 10164
上記のポート番号のいずれかがすでにインストール時に予約されている場合は、Common Agent Container が占有するポート番号を次のようにして変更します。
Common Agent Container の cacaoadm コマンドの詳細については、cacaoadm のマニュアルページを参照してください。このマニュアルページをコマンド行に表示できない場合は、MANPATH が正しく設定されているか確認します。「MANPATH の設定」を参照してください。
ルートとして、Common Agent Container 管理デーモンを停止します。
# /opt/SUNWcacao/bin/cacaoadm stop |
次の構文を使用して、ポート番号を変更します。
# /opt/SUNWcacao/bin/cacaoadm set-param param=value |
たとえば、SNMP アダプタが占有するポートをデフォルトの 10161 から 10165 に変更するには、次のようにします。
# /opt/SUNWcacao/bin/cacaoadm set-param snmp-adaptor-port=10165 |
Common Agent Container 管理デーモンを再起動します。
# /opt/SUNWcacao/bin/cacaoadm start |
ルートとして、Common Agent Container 管理デーモンを停止します。
# /opt/sun/cacao/bin/cacaoadm stop |
次の構文を使用して、ポート番号を変更します。
# /opt/sun/cacao/bin/cacaoadm set-param param=value |
たとえば、SNMP アダプタが占有するポートを 10161 から 10165 に変更するには、次のようにします。
# /opt/sun/cacao/bin/cacaoadm set-param snmp-adaptor-port=10165 |
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
通常の操作条件では、これらのキーはデフォルトの設定のままでかまいません。キーの安全性が危うくなったために、キーを再生成することが必要な場合は、次の手順でセキュリティーキーを再生成できます。
ルートとして、Common Agent Container 管理デーモンを停止します。
# /opt/SUNWcacao/bin/cacaoadm stop |
セキュリティーキーを再生成します。
# /opt/SUNWcacao/bin/cacaoadm create-keys --force |
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」を参照してください。
ルートとして、Common Agent Container 管理デーモンを停止します。
# /opt/sun/cacao/bin/cacaoadm stop |
セキュリティーキーを再生成します。
# /opt/sun/cacao/bin/cacaoadm create-keys --force |
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 サブコマンドは実行できません。
エラーメッセージに示されている場所からロックファイルを削除します。
ここでは、コンポーネントについてのさまざまなヒントを提供し、役立つマニュアルを紹介します。
ここで説明する内容は、次のとおりです。
項目 |
詳細 |
---|---|
設定ファイル |
AMConfig.properties Solaris OS の場合: /etc/opt/SUNWam/config Linux の場合: /etc/opt/sun/identity/config |
ログファイルとデバッグファイル |
ログファイルのディレクトリ:
|
デバッグモード |
『Sun Java System Access Manager 7 2005Q4 Developer’s Guide』の「Auditing Features」の章を参照してください。 |
項目 |
詳細 |
---|---|
ログファイル |
|
トラブルシューティング |
を参照してください。 |
項目 |
詳細 |
---|---|
ログファイル |
ログファイルのディレクトリ: 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』を参照してください。 |
項目 |
詳細 |
---|---|
ログファイル |
管理サービス (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』を参照してください。 |
項目 |
詳細 |
---|---|
ログファイル |
デフォルトのログファイル: uwc-deployed-path/logs/uwc.log |
トラブルシューティング |
『Sun Java System Communications Express 6 2005Q4 Administration Guide』の第 5 章「Troubleshooting」を参照してください。 |
項目 |
詳細 |
---|---|
ログファイル |
実行時ログファイル: /opt/SUNWcomm/log |
トラブルシューティング |
項目 |
詳細 |
---|---|
ログファイル |
デフォルトのログファイル: 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』を参照してください。 |
項目 |
詳細 |
---|---|
ログファイル |
インストールログファイル: 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 のトラブルシューティングについては、クライアントのオンラインヘルプおよび『Sun Java System Instant Messaging 7 2005Q1 Administration Guide』を参照してください。
項目 |
詳細 |
---|---|
トラブルシューティング |
『Sun Java System Message Queue 管理ガイド』の「問題のトラブルシューティング」の章、および次の MQ フォーラムを参照してください。http://swforum.sun.com/jive/forum.jspa?forumID=24 |
パフォーマンス |
『Sun Java System Message Queue 3 2005Q4 管理ガイド』の「メッセージサービスの分析と調整」を参照してください。 |
項目 |
詳細 |
---|---|
実行ファイルの場所 |
/opt/SUNWmsgsr/sbin |
ログファイル |
MessagingServer-base/data/log |
トラブルシューティング |
『Sun Java System Messaging Server 6 2005Q4 Administration Guide』を参照してください。 |
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 |
トラブルシューティング |
Portal Server は、Access Manager と同じログファイルとデバッグファイルを使用します。
desktop.debug
desktop.dpadmin.debug
dpadmin、par、rdmgr、および sendrdm という Portal Server コマンド行ユーティリティーには、デバッグメッセージを生成するためのオプションがあります。それらのオプションについては、『Portal Server 管理ガイド』を参照してください。
Portal Gateway のデバッグログは次のディレクトリに格納されます。
Solaris OS の場合: /var/opt/SUNWps/debug
Linux の場合: /var/opt/sun/portal/debug
Access Manager 管理コンソールからロギングをオンにした場合、NetFile などの Portal Server サービスのログは /var/opt/SUNWam/debug に作成されます。
項目 |
詳細 |
---|---|
ログファイル |
Application Server のインスタンスログ: Solaris OS の場合: /var/opt/SUNWsoar/domains/registry/logs/server.log Linux の場合: /var/opt/sun/SUNWsoar/domains/registry/logs/server.log |
トラブルシューティング |
項目 |
詳細 |
---|---|
ログファイル |
デフォルトのログディレクトリ: /var/cluster/logs/install エラーメッセージ: /var/adm/messages |
トラブルシューティング |
『Sun Cluster Software Installation Guide for Solaris OS』を参照してください。 |
項目 |
詳細 |
---|---|
ログファイル |
Web Server のログファイルは 2 種類あります。errors ログファイルと access ログファイルです。どちらも次のディレクトリに格納されます。
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 |
デバッグモード |
次のオプションを使用できます。
|
項目 |
詳細 |
---|---|
ログファイル |
デフォルトのログの場所: /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。 |
このマニュアルに記載されている次の情報も、トラブルシューティングに役立ちます。
第 6 章「インストール後のコンポーネントの設定」には、インストール後設定の実行手順が含まれています。
第 8 章「コンポーネントのアンインストール」には、Java ES ソフトウェアのアンインストール時に発生する可能性のある問題に関する情報が含まれています。