![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
アプリケーション・サーバーの始動または再始動の問題
サーバーの処理が開始しない、または開始してもエラーになる場合は、以下のトピックが問題を診断するのに役立ちます。
インストール・プログラムは正常に完了しているが、アプリケーション・サーバーが始動しない、または始動してもエラーになる
- アプリケーション
・サーバーのログ・ファイルをブラウズして、手掛かりを見つける。(Browse
the Application
Server log files for clue.)ログ・ファイルはデフォルトで次の場所にあります。
profile_root/logs/server_name/SystemErr.log および SystemOut.log
profile_root¥logs¥server_name¥SystemErr.log および SystemOut.log
profile_root/logs/server_name/SystemErr.log および SystemOut.log
サーバーの進行を監視するには、tail -f profile_root/ logs/server_name/SystemOut.log コマンドを使用すると便利です。
- Web モジュール、エンタープライズ Bean、およびメッセージング・リソースなどのモジュールを持つ
特定のリソースに関連するエラーまたは警告をすべて調べます。
何らかのエラーか警告が見つかった場合は、アプリケーション・サーバーの
構成ファイルでそのリソースの構成設定を調べます。
その後、サーバーを再始動して、このコンポーネントで問題が生じるかどうかを確認してください。
例えば、Windows システムの基本 (非分散) 構成では、profile_root¥config¥cells/ApplicationServerCell¥nodes¥node_name¥servers¥server_name¥server.xml を参照し、このリソースのプロパティーの XML タグについて調べます。その initialState 値を、START から STOP に変更します。
例えば、profile_root/config/cells/ApplicationServerCell/nodes/node_name/servers/server_name/server.xml を参照し、このリソースのプロパティーの XML タグについて調べます。 その initialState 値を、START から STOP に変更します。
- インフォメーション・センター・ナビゲーションの「Reference」ビューをクリックし、 ナビゲーション・ツリーで「メッセージ」を展開して、 メッセージ参照テーブルにエラーまたは警告メッセージがないか検索します。
- アプリケーション・サーバーを作成したら、新しいサーバーの構成設定を保存する前に、ノードを同期する必要があります。
ノードを同期しないと、新しいサーバーが始動しない可能性があります。
- アプリケーション・サーバーがすべてリストされているアプリケーション・サーバー・ページで、「設定」をクリックします。
- 選択していない場合は、「ノードと変更を同期化」を選択します。
- 「適用」をクリックし、次に「アプリケーション・サーバー」をクリックしてアプリケーション・サーバーのリストに戻ります。
- 「保存」をクリックして、新しいサーバーの構成設定を保存します。
- アプリケーション・サーバーが Network Deployment または複数サーバー構成の一部である場合には、以下を行います。
構成にアプリケーション・サーバーを追加したことを確認します。
- デプロイメント・マネージャーとノード間で構成の同期が取られていることを確認します。 自動同期が実行されている場合は、その同期が完了するまで待機してください。 手動で同期させる場合には、クラスター内の各ノードに同期を要求します。
アプリケーション・サーバーを始動する前:
- 次のコマンドを実行してデプロイメント・マネージャー・プロセスを開始します。
app_server_root/bin/startManager.sh
app_server_root¥bin¥startManager.bat
- アプリケーション・サーバーが稼働しているノードをデプロイメント・マネージャーに結合する、一回限りのステップを完了します。 このステップは、ノードが 1 つのみの場合にも実行する必要があります。 また、両方のプロセスが同じ物理サーバー上にある場合でも、実行しなければなりません。
- デプロイメント・マネージャーが稼働中であることを確認します。次に、profile_root/bin ディレクトリーから addNode nodename コマンドを実行します。 例えば、Linux または UNIX のシステムでは、 以下のコマンドにより、アプリケーション・サーバーがデプロイメント・マネージャーに追加されます。
addNode.sh localhost 8879 -includeapps -startingport 3333
デプロイメント・マネージャーは、デフォルトの SOAP ポート 8879 を使用します。どちらのプロセスも同一マシン上にあります。 アプリケーション・サーバー上にあるインストール済みのすべてのアプリケーシ ョン (システム・アプリケーションである管理コンソールを除く) は、デプロイメント・マネージャーにインストールされます。
startingport パラメーターは、同一マシン上にノード・エージェント・プ ロセスが共存する問題を回避します。 ノード・エージェント・プロセスのすべてのポートは、ポート番号 3333 で 始まります。-portprops パラメーターを使って特定のポートを割り当てることもできます。
詳しくは、addNode コマンドの説明を参照してください。
- app_server_root/bin/startNode.sh または app_server_root¥bin¥startNode.bat と入力して、実行対象のアプリケーション・サーバーをホスティングするノード上で、ノード・マネージャー・プロセスを開始します。
- 次のコマンドを実行してデプロイメント・マネージャー・プロセスを開始します。
アプリケーション・サーバーを始動する前に、startNode Qshell スクリプトを使用して、始動するアプリケーション・サーバーをホスティングするノード上で、ノード・エージェント・プロセスを開始します。
- アプリケーション・サーバーのコンソール上に表示するよう指定した論理名に、 - / ¥ : * ? " < > などの無効文字が含まれていないか、および先頭または末尾に スペースが含まれていないかどうかを確認します。
正常にインストールできたにも関わらずデプロイメント・マネージャーを開始できない場合は、profile_root/logs/server_name/SystemErr.log ファイルおよび SystemOut.log ファイルのメッセージを調べます。
正常にインストールできたにも関わらずデプロイメント・マネージャーを開始できない場合は、profile_root/logs/server_name/SystemErr.log ファイルおよび SystemOut.log ファイルのメッセージを調べます。
- Apache Derby を使用していて、アプリケーション・サーバーの始動中に 「エラー XSDB6: Apache Derby の別のインスタンスが、既にデータベース databaseName をブートしている可能性があります」というエラーを受信した場合、 詳細については、トピック『データ・アクセスの問題』を参照してください。
アプリケーション・サーバーを実行するのにルート以外のユーザー ID を使用している場合は、以下のことを確認してください。
- ルート以外のユーザーが app_server_root/temp ディレクトリーに対する書き込みアクセス権限を持っている。
- JVM が、app_server_root/config/plugin-cfg.xml ファイルに対する書き込みアクセス権限を持っている。
- ルート以外のユーザーが logs ディレクトリーに対するアクセス権限を持っている。
アプリケーション・サーバーを実行するのに、QEJBSVR 以外のユーザー・プロファイルを使用している場合は、以下のことを確認してください。
- ユーザー・プロファイルで、そのグループ・プロファイルとして QEJBSVR が指定されている。
- QEJBSVR が、profile_root ディレクトリー下のすべてのファイルとディレクトリーのオーナーである。
Qshell セッションの以下のコマンドを使用して、QEJBSVR をオーナーとして設定できます。
chown -R QEJBSVR profile_root
- アプリケーション・サーバーが制限モードで始動していない 可能性があります。アプリケーション・サーバーは、内部サーバー・クラスへのアクセスを許可するようにも、 制限するようにも構成できます。デフォルトではアクセスは許可されています。アクセスを 制限すると、サーバーが始動しない場合があります。アプリケーション・サーバーが 「制限」モードで始動しない場合は、内部クラスへのアクセスを「許可」に 変更してください。
アプリケーション・サーバーの再始動後に、SystemOut.log にエラー・メッセージが記録されることがある
「ホスト hostname およびポート portnumber のソケット・バインドに失敗しました。
ポートが使用中の場合があります。」
この問題は、ネットワークが遅く、アプリケーションが停止し、再始動したときにメッセージ・テキスト中にリストされたポートが listen を完了できなかった場合に現れることがあります。
これが問題であることを検査するには、ポート状況を確認します。
どのポートも listen していないことを確認します。次のコマンドを使用します。
netstat -a
どのポートも listen していないことを確認します。この CL コマンドを使用します。
NETSTAT *CNN
- サーバーを再始動します。
メッセージ「DiscoveryService.sendQuery」例外が FFDC ログ・ファイルに出力される
デプロイメント・マネージャーを開始すると、デプロイメント・マネージャーは、それ自体のセル内で構成済みノード・エージェントを見つけようとします。デプロイメント・エージェントは、セル内にノード・エージェントが見つからなかった場合、デプロイメント・マネージャーが見つけなかったノード・エージェントごとに、First Failure Data Capture (FFDC) ログ・ファイルに例外を書き込みます。ノード・エージェントが実行されていることを想定していなかった場合、この例外は無視してかまいません。ノード・エージェントが実行されていることを想定していた場合は、たとえその想定どおりであったとしても、FFDC ログ・ファイルには、デプロイメント・マネージャーがノード・エージェントを見つけられなかった理由を判別するのに役立つ追加情報が含まれている場合があります。
![[IBM i]](../images/iseries.gif)
WebSphere Application Server バージョン 8.5.0.1 の適用後に IBM i でサーバーが再始動しない
8.5.0.1 の適用後に IBM i でサーバーが再始動しない場合、メッセージ「CWWKE0044E: サーバー・ディレクトリーに対する書き込み許可がありません。(There is no write permission for server directory.) 」を受け取ることがあります。
このエラーは、QEJBSVR ユーザーによって OS 統合で開始した場合に、IBM i でのみ発生します。
<serverName>/workarea/.sCommandAuth ディレクトリーの内容を削除するスクリプトでサーバー・コマンドの呼び出しをラップすることで、一時的にこれを解決することができます。