Web サーバー・プラグインのトラブルシューティングのヒント

以下のトピックは、Web サーバー・プラグインの問題を診断するのに役立ちます。

Web サーバー・プラグインの使用中に、問題が生じた場合は、以下のステップを試みてください。

手掛かりについては、ファイル plugins_root/logs/web_server_name/http_plugin.log を参照してください。メッセージ表でエラー・メッセージまたは警告メッセージを検索します。
以下の Web サーバーのエラー・ログおよびアクセス・ログを検討して、Web サーバーに問題があるかどうかを調べる。
- IBM® HTTP Server および Apache: access.log および error.log。
- Domino ® Web サーバー: httpd-log および httpd-error。
- Sun Java™ System: access および error。
- Microsoft IIS: timedatestamp.log。

これらのファイルで問題の原因が明らかにならない場合は、以下の追加ステップに従ってください。

プラグインの問題判別ステップ

プラグインにより、非常に読みやすい、問題の解決に役立つトレースが提供されます。 config/plugin-cfg.xml ファイルの LogLevel 属性を Trace に設定することにより、要求処理の進行に沿って、問題の原因解明を行うことができます。

注: ラージ・ファイル・サポートが有効になっている Veritas ファイル・システムを使用している場合、最大 2 テラバイトのファイル・サイズが許可されます。この場合、plugin-cfg.xml ファイルの LogLevel 属性を LogLevel=Trace に設定すると、http_plugin.log ファイルのサイズが急速に大きくなり、ファイル・システムで利用可能なスペースをすべて消費する場合があります。このため、LogLevel 属性の値は ERROR または DEBUG にして、CPU の使用率が高くなることを回避する必要があります。

ハイレベルで、以下のステップを実行します。

プラグインが要求を受け取る。
プラグインが、plugin-cfg.xml ファイルで定義された経路を検査する。
サーバー・グループを検索する。
サーバーを検索する。
トランスポート・プロトコル (HTTP または HTTPS) を選出する。
要求を送信する。
応答を読み取る。
その応答をクライアントに書き戻す。

以下のように、単一要求のトレースを介して読み取りを行うことにより、これを極めて明確に表示することができます。

最初のステップは、プラグインが Web サーバーに正常にロードされたかどうか判別することです。
- http_plugin.log ファイルが作成されたことを確認する。
- 作成された場合は、それを参照して、プラグインの初期化中に何らかの障害が起こったこと示すエラー・メッセージがあるかどうかを調べる。エラーがなかった場合、プラグインが正常に始動したことを示す次のスタンザを探す。以下のような、Web サーバーを始動した時間に対応するメッセージのタイム・スタンプを確認してください。
```
[Thu Jul 11 10:59:15 2002] 0000009e 000000b1 - PLUGIN: ------------System Information---------- 
[Thu Jul 11 10:59:15 2002] 0000009e 000000b1 - PLUGIN: Bld date: Jul  3 2002, 15:35:09 
[Thu Jul 11 10:59:15 2002] 0000009e 000000b1 - PLUGIN: Web server: IIS 
[Thu Jul 11 10:59:15 2002] 0000009e 000000b1 - PLUGIN: Hostname = SWEETTJ05 
[Thu Jul 11 10:59:15 2002] 0000009e 000000b1 - PLUGIN: OS version 4.0, build 1381, 'Service Pack 6' 
[Thu Jul 11 10:59:15 2002] 0000009e 000000b1 - PLUGIN: -------------------------------------------- 
```
- 共通するエラーとしては、以下のようなものあります。
  lib_security: loadSecurityLibrary: gsk Failed to load gsk library
  IBM Global Security Kit (GSKit) がインストールされていないか、間違ったバージョンの GSKit がインストールされています。どの状態が発生しているかを判別するには、以下のようにします。
  - Windows プラットフォームでは、以下のファイルを検索します。 gsk8ssl.dll
  - UNIX プラットフォームでは、 /usr/lib ディレクトリーで libgsk8*.so ファイルを検索します。
  適切なファイルが見つからない場合は、正しいバージョンの IBM Global Security Kit (GSKit) を使用してプラグインを再インストールし、これで問題が修正されるかどうかを確認してください。
  ws_transport: transportInitializeSecurity: Keyring wasn't set
  
  構成ファイルに定義された HTTPS トランスポートの終了が早すぎたため、鍵リングと stash ファイルのプロパティーの定義が含まれませんでした。 XML 構文を調べて、このメッセージの後に続くエラー・メッセージで指定された行番号を確かめ、トランスポートが終了する前に、トランスポート・エレメントに鍵リングと stash ファイルの定義が含まれたかどうかを確認してください。
- http_plugin.log ファイルが作成されていない場合は、Web サーバーのエラー・ログを確認して、プラグインに関するエラー・メッセージ (プラグインのロードが失敗した原因を示すメッセージ) がログに記録されているかどうかを確認してください。通常の原因としては、 Web サーバー環境でプラグインを正しく構成できなかったことが挙げられます。 Web サーバー・プラグインで使用している Web サーバーの構成に関する資料を確認してください。
プラグインに関して、および構成で定義された各種アプリケーション・サーバーに関して、ネットワーク接続の問題があるかどうかを判別します。これらに関して問題がある場合には、通常は次のメッセージが表示されます。
```
hostname:port number への接続に失敗しました (error code):error message(local port port number)
```
connect() 呼び出しの失敗は、さまざまな理由から発生します。
- マシンを PING して、それらのマシンが正しくネットワークに接続されているかを確認します。マシンを PING できない場合、プラグインがマシンと通信することはできません。この問題の原因としては、以下のことが考えられます。
  - ファイアウォールのポリシーにより、プラグインからアプリケーション・サーバーへのトラフィックが制限されている。
  - マシンが同じネットワーク上にない。
- マシンを PING できる場合、問題の原因として考えられるのは、ポートがアクティブでないことです。ポートがアクティブでないのは、アプリケーション・サーバーまたはクラスターが始動されていないか、アプリケーション・サーバーが何らかの理由でダウンしているためであると考えられます。問題がこれであることを検査するには、接続に失敗しているポートに手動で Telnet 接続してみます。アプリケーション・サーバーが稼働していないポートに Telnet 接続できない場合、プラグインが正常に接続できるようにするには、先にその問題を解決する必要があります。
サーバーがインストールされているマシン上のその他のアクティビティーによって、サーバーの要求に対するサービス提供能力が低下しているかどうかを判別します。タスク・マネージャー、プロセッサー ID、またはその他の外部ツールで計測される、プロセッサー使用状況をチェックして、以下のことを調べてください。
- 予想外のことでないかどうか。
- 安定しておらず、不規則であるかどうか。
- クラスター内の新規追加メンバーが使用されていないことを示しているどうか。
- 障害が発生したメンバーに対する修正が行われたにもかかわらず、メンバーが使用されていないことを示しているかどうか。
管理コンソールでサーバーの状況を確認します。
管理コンソールを調べて、アプリケーション・サーバーが始動していることを確認してください。管理コンソールでエラー・メッセージを確認するか、 JVM ログを調べてください。
管理コンソールで、問題の発生したアプリケーション・サーバーを選択し、そこにインストールされたアプリケーションを表示して、アプリケーションが始動していることを確認します。

これらのステップで問題が解決できない場合は、以下を行ってください。

Web ページとそのコンテンツが表示されない原因となる可能性がある特定の問題については、資料の「Web リソース (JSP ファイル、サーブレット、html ファイル、イメージなど) が表示されない」を参照してください。
「問題の診断と修正: 学習用リソース」のリンクを使用して、問題が特定され、文書化されているかどうかを確認してください。
類似した問題が見つからない場合、または提供されている情報では問題が解決されない場合は、 IBM サポートに連絡して支援を受けてください。

Web サーバーが非セキュア・トランスポートを使用する場合の動作の変更

セキュア・トランスポートと非セキュア・トランスポートが定義されていて、システム障害のためにセキュア・トランスポートが使用できない場合に、Web サーバー・プラグインは、非セキュア・ポートを使用します。これはデフォルト動作です。

この動作は、 WebSphere Application Server バージョン 8.5.5で変更されました。セキュア接続の試行中にシステム障害が発生した場合、非セキュア・トランスポートがあっても、Web サーバー・プラグインは、そのトランスポートを使用しません。管理者は、問題について通知を受け、セキュア接続を使用して修復できます。

この問題に管理者が対処するために使用できるオプションは 3 つあります。

HTTPS トランスポートが使用可能になるように SSL 問題を修正する (推奨オプション)。
SSL が使用されていない場合は HTTPS トランスポートを削除し、プラグインを再生成する。
plugin-cfg.xml ファイル内に UseInsecure=true を設定して、以前のデフォルト動作に戻す。

以前のデフォルトの動作に戻す場合は、管理コンソールでカスタム・プロパティーを設定してその動作を使用可能にします。 Web サーバー > <webserver_name> > 「プラグイン・プロパティー」 > 「カスタム・プロパティー」を選択し、 UseInsecure を trueに設定します。

既知の問題とその解決策について IBM サポートから入手可能な最新情報については、 IBM サポート・ページの以下のトピックを参照してください。 PMR を開く前にこれらのページを参照してください。問題の解決に必要な情報を収集する時間を節約できる資料が含まれているためです。

IBM サポート・ページには、以下のトピックが役立つ場合もあります。