このトピックでは、WebSphere Application Server 製品のインストールのトラブルシューティングを説明します。
WebSphere Application Server の Web サーバー・プラグインのトラブルシューティング情報を 検索する場合は、Web サーバー・プラグインのインストールおよび除去のトラブルシューティング を参照してください。このトピックでは、プラグインについては説明しません。
このトピックは、WebSphere Application Server 製品のインストール後に使用します。
WebSphere Application Server 製品の正常なインストールでは、コア・プロダクト・ファイルがインストール され、server1 アプリケーション・サーバーが作成されます。
インストールが正常に行われなかった場合は、このトラブルシューティング情報を使用して 問題を訂正してください。
インストールが正常に行われなかったとき、このトピックを使用してログ・ファイルを解釈し、考えられる問題を診断する助けとします。
インストール・ウィザードは、インストールの終了時にファースト・ステップ・コンソールを 始動することができます。「インストール検査」を選択します。テスト結果の概要を profile_root/logs/ivt.log ファイルで調べます。すべてのエラーを訂正し、再試行します。カスタム・インストールを実行した場合、 デフォルト・プロファイルのロケーションは、インストール中にユーザーが選択したプロファイル・インストール・ルート・ディレクトリー の中です。
プロファイル管理ツール または manageprofiles コマンドを使用して、 別のプロファイルを作成した場合、プロファイルのロケーションおよび名前は、例に表示されるものとは異なります。
詳しくは、インストール済みファイルのチェックサムの検査 を参照してください。
installver コマンドからの出力を、次のステップで説明されるインストール・ログ・ファイルと比較します。
インストールおよびプロファイル作成状況は、app_server_root/logs/install/log.txt ファイル、app_server_root/logs/manageprofiles/profile_name_create.log ファイル、および profile_root/logs/pctLog.txt ファイルに 記録されます。
インストールの初期にエラーが発生した場合は、システム一時領域の log.txt ファイルを探します。 インストール・プログラムは、インストールの最後に一時領域から logs ディレクトリーにログをコピーします。
インストール中、app_server_root/logs/install/log.txt ファイルの単一エントリーが、 一時ログ・ファイル (Windows プラットフォームの場合は %TEMP%¥log.txt、AIX または Linux などの プラットフォームの場合は /tmp/log.txt) を指します。 インストール・プログラムは、インストールの最後に、 このファイルを一時ディレクトリーから app_server_root/logs/install/log.txt ロケーションにコピーします。
インストールが失敗し、log.txt ファイルに 一時ディレクトリーに対するこの 1 つのポインターしかない場合は、 一時ディレクトリーの log.txt ファイルを開きます。 このログに、インストールの失敗についての手掛かりが含まれる場合があります。
アンインストールによって、app_server_root/logs/uninstall/log.txt ファイルが作成されます。
InstallShield MultiPlatform (ISMP) によって インストール・ウィザードが開始されない場合は、ログに情報が記録されます。
install -options fully_qualified_options_response_file_name -silent -log # !fully_qualified_log_file_name @ALL
install -options "/usr/IBM/WebSphere/silentFiles/myresponsefile.txt" -silent -log # !/usr/IBM/WebSphere/myOptionFiles/log.txt @ALL
install -options "/opt/IBM/WebSphere/silentFiles/myresponsefile.txt" -silent -log # !/opt/IBM/WebSphere/myOptionFiles/log.txt @ALL
install.exe -options "C:¥IBM¥WebSphere¥silentFiles¥myresponsefile.txt" -silent -log # !C:¥IBM¥WebSphere¥silentFiles¥log.txt @ALL
ログ・ファイルの 名前と位置
以下の情報は、製品ディスク上のインストール可能なすべてのコンポーネントのログ・ファイルを示します。
IBM HTTP Server のログ・ファイル
Windows システムのログ・パス名 | AIX または Linux などの オペレーティング・システムのログ・パス名 |
---|---|
|
|
Application Client for WebSphere Application Server のログ・ファイル
Windows システムのログ・パス名 | AIX または Linux などのシステムの オペレーティング・システム・ログ・パス名 |
---|---|
|
|
ログ (Log) | 内容 | インディケーター |
---|---|---|
app_server_root /logs/install/log.txt | すべてのインストール・イベントを記録します。 |
|
app_server_root/logs/wasprofiles/wasprofile_create_profile_name.log |
|
|
app_server_root/logs/install/ installconfig.log.gz |
|
|
profile_name_create.log ファイルの説明
profile_name_create.log ファイルは、 最後のプロファイルの作成時に発生するイベントのレコードが含まれる XML ファイルです。
<record> <date>2004-09-08T11:51:39</date> <millis>1094658699225</millis> <sequence>0</sequence> <logger>com.ibm.ws.profile.WSProfile</logger> <level>INFO</level> <class>com.ibm.ws.profile.WSProfile</class> <method>getRegistryFile</method> <thread>10</thread> <message>Returning registry file at: C:¥IBM¥WebSphere¥AppServer¥properties¥profileRegistry.xml </message> </record>
アプリケーション・サーバー・プロファイルの作成時に作成されるログ・ファイル
コア・プロダクト・ファイル内で作成されるログに加えて、 次のログが profile_root/logs ディレクトリーに作成されます。
アプリケーション・サーバー・プロファイルを作成するときに、 プロファイル管理ツール および manageprofiles コマンドの両方によって、 ログが作成されます。
このログは、 manageprofiles コマンドを直接使用する場合には 作成されません。
このログは、製品のインストール時には作成されません。
WebSphere Application Server の Web サーバー・プラグインのログ・ファイル
ログ・ファイルの説明およびその他のトラブルシューティング情報については、Web サーバー・プラグインのインストールおよび除去のトラブルシューティング を参照してください。
app_server_root/logs/instconfig.log ファイルには、 製品の正常動作を妨げる可能性のある ANT 構成の問題が表示されています。 AIX または Linux などのシステムの場合、このログ・ファイルは存在しません。
ANT スクリプトの問題を手動で診断し、修正する方法については、 失敗した ANT 構成スクリプトの診断 を参照してください。
IBM サポートはカスタマーのための作業をキューに入れ、テストまたはデバッグ修正を提供する場合があります。 修正用の共通ロケーションは、app_server_root/classes ディレクトリーです。
デフォルトでは、app_server_root/classes ディレクトリーが最初に WebSphere Application Server クラスパスで選択され、他のクラスをオーバーライドします。
このディレクトリーに修正を置くことにより、 ユーザーは、修正が問題を実際に解決するかどうかを検査できます。 修正が問題を解決することを検査したら、app_server_root/classes ディレクトリーから修正を削除して、システムを作業状態に戻します。
app_server_root/classes ディレクトリーからこのような修正を除去しない場合は、 エラーが発生することがあります。
install -is:javaconsole
install -is:javaconsole > captureFileName.txt 2>&1
install.exe -is:javaconsole
install -is:javaconsole > drive:¥captureFileName.txt
install -W Setup.product.install.logAllEvents="true"
install -W Setup.product.install.logAllEvents="true"
Java プロセスが存在せず、メッセージも記述されていない場合は、 同じログでその他のエラーを検査します。 すべてのエラーを訂正し、再試行します。
SystemOut.log および SystemErr.log ファイルは、Application Server プロファイルの profile_root/logs/server1 (AIX または Linux などのプラットフォームの場合) ディレクトリー、または profile_root¥logs¥server1 (Windows プラットフォームの場合) ディレクトリーにあります。
ご使用のアプリケーション・サーバーおよび Web サーバーを 開始し、IP アドレスとスヌープ・サーブレットを使用して、ご使用の環境をテストします。
コマンド・ウィンドウを使用して、IBM HTTP Server のインストール済みイメージ、 またはユーザーの Web サーバーのインストール済みイメージに移動します。 IBM HTTP Server に適切なコマンドを実行して、Web サーバーを始動します。 コマンドの例を以下に示します。
IBM HTTP Server をコマンド行から始動する方法は、以下のとおりです。
HTTP トランスポート・ポートはデフォルトで 9080 であり、 すべてのプロファイルで固有でなければなりません。このポートは、default_host という名前の仮想ホストと関連し、 その仮想ホストは、インストール済みの DefaultApplication およびインストール済みサンプルをホストするよう構成されています。 スヌープ・サーブレットは、DefaultApplication の一部です。ポートを変更して、 実際の HTTP トランスポート・ポートに一致させます。
どちらかの Web アドレスで 「Snoop Servlet - Request/Client Information」ページが表示されるはずです。
以下のステップを使用することによって、 自動伝搬機能がリモート IBM HTTP Server に対して動作することを確認します。 この手順は、ローカル Web サーバーでは必須ではありません。
「Could not connect to IHS Administration server error」
HTTP Admin ポートはデフォルトで 9060 であり、各スタンドアロン・アプリケーション・サーバーの管理コンソールに対して 固有でなければなりません。このポートは、admin_host という名前の仮想ホストと関連し、 その仮想ホストは、システム・アプリケーションとしてデフォルトでインストールされる 管理コンソールをホストするよう構成されています。 このポートを、実際の HTTP Admin ポートと一致するように変更します。
インストール後、 管理コンソールにアクセスする際に問題が発生した場合は、installAdminConsole.log ファイルで障害の原因を確認してください。 システムの一時ディレクトリーをクリーンアップし、wsadmin スクリプト機能を 使用して管理コンソールを再インストールします。
サーバーが始動します。管理コンソールが始動します。管理コンソールには、 ブラウザーを介してアクセスできます。 管理コンソールがログインを受け入れます。
デフォルトでは、 Java 2 SDK がドメイン・ネーム・サービス (DNS) ネーミング・ルックアップ用の IP アドレスをキャッシュに入れます。 ホスト名が正常に解決されると、IP アドレスはキャッシュにとどまります。 デフォルトでは、キャッシュ・エントリーはいつまでも残ります。
このデフォルトの IP キャッシング・メカニズムが、以下の問題シナリオが示すように、 問題を引き起こす場合があります。
問題例 1
host1.ibm.com のアプリケーション・サーバーの初期 IP アドレスが 1.2.3.4 であるとします。 host2.ibm.com のクライアントが host1.ibm.com の DNS ルックアップを実施すると、 クライアントがアドレス 1.2.3.4 をキャッシュに保管します。それ以後の DNS 名ルックアップでは、キャッシュされた値である 1.2.3.4 が戻されます。
キャッシュされた値は、host1.ibm.com の IP アドレスが、例えば 5.6.7.8 に変更されるまでは、問題とはなりません。 host2.ibm.com のクライアントは現在の IP アドレスを取得するのではなく、 常に、キャッシュに入っている以前のアドレスを取得します。
そうなると、クライアント・プロセスを停止して再始動するまでは、クライアントは host1.ibm.com に到達できません。
問題例 2
host1.ibm.com のアプリケーション・サーバーの初期 IP アドレスが 1.2.4.5 であるとします。アプリケーション・サーバーの IP アドレスが変わらなくても、ネットワークの障害により、キャッシュ内の IP アドレスとして例外コードが記録されることがあります。この例外コードは、クライアントが稼働中のネットワーク上で再始動するまで、キャッシュ内にとどまります。
例えば、host2.ibm.com のクライアントがケーブルが抜けたためにネットワークから切り離された場合、 host1.ibm.com のアプリケーション・サーバーの切断ルックアップは失敗します。 この失敗により、IBM Developer Kit が、IP アドレス・キャッシュに特別な例外コード・ エントリーを書き込みます。
それ以後の DNS 名ルックアップでは、例外コード java.net.UnknownHostException が戻されます。
Java 2 SDK の詳細
Java 2 Platform Standard Edition (J2SE) 1.4.2 の Web サイト および Java 2 Platform Standard Edition (J2SE) 1.5 の Web サイト で説明されている private sun.net.inetaddr.ttl プロパティー は、J2SE 1.4.2 (WebSphere Application Server バージョン 5.1 および バージョン 6.0) および J2SE 1.5 (WebSphere Application Server バージョン 6.1) の両方で動作します。
インストール・ウィザードの prereqChecker プログラムは、そのファイルを使用し、オペレーティング・システムのバージョンを確認します。 オリジナル・バージョンを復元できない場合は、サポートされていないオ ペレーティング・システムに関するオペレーティング・システム・レベル・チェックのメッセージを無視してください。 警告が表示されても、インストールは正常に継続されます。
この手順の結果、インストール中に発生する可能性のあるエラーをデバッグします。
デバッグおよびレポートについての説明の詳細は、インストールの問題 を参照してください。 インストールのトラブルシューティングについての詳細は、インストール・コンポーネントのトラブルシューティングのヒント を参照してください。
IBM サポートから入手可能な既知の問題およびその解決法に関する最新の情報については、IBM サポート・ページを参照してください。
IBM サポートが提供する資料を参照すれば、 問題を解決するために必要な情報を集める時間を短縮することができます。 PMR を開く前に、IBM サポート・ページを参照してください。