さらに、他にも役に立つセクションを是非ご覧ください。
デフォルトでは、Windows サービスは SYSTEM ユーザーとして実行されます。 この「ネットワークドライブにアクセスできない」問題の原因は、SYSTEM ユーザーは、ネットワークリソースにアクセス権がないからです。 もし、アプリケーションが Windows サービスとして正常に動作しているならば、 まず最初に試してみることは、コンソールアプリケーションとして正常に動作する時と 同じユーザーでログインして、サービスを動かしてみることです。
その手順を説明すると、
そうすると、サービスはコンソールアプリケーションとして実行されていたのと同じ環境で実行されるため、すべてが正しく動作するはずです。
セキュリティ要件に応じて、サービス専用の新しいユーザーを作成および設定をすることもできます。
一部のシステムでは、ドライブレター(ドライブを示すアルファベット)にマップされたドライブは、システムの再起動時に、 本当のユーザーが実際にログオンしてドライブに接続するまで、常にアクセスできるわけではありません。 回避策としては、マッピングされたドライブ文字を使用するのではなく、UNC構文(マシン名を含むフルパス)を使用して 直接ドライブを参照することです。
//host/share/path
[CTRL]+[BREAK] や [CTRL]+[\]のキー操作、あるいは、API 経由でスレッドダンプを要求すると、ログに次のようなメッセージが表示され、JVM が再起動します。
wrapper | JVM exited unexpectedly.
まず、JVM を起動する際に、[-Xrs フラグ] を指定していないことを確認してください。 このフラグは、Wrapper を使わずに Java を動かす環境では便利ですが、Wrapper の様々なシステムシグナルに応答できる能力を損ないます。
Wrapper の設定で、 JVM がシステムシグナルを無視するには、 代わりに[wrapper.ignore_signals] プロパティをご利用ください。 設定を変更する際には、必ず事前に説明を読んでください。
Wrapper で COM アプリケーションを動かそうとすると、問題が起きるという報告も数例あがっています。 アプリケーションがスタンドアローンとして単独で正常に動作する場合でも、Wrapper で動かそうとすると、次のようなエラーが出る場合があります。
Caught java.lang.NullPointerException: name can't be null while loading driver com.sun.comm.Win32Driver
「COM API」 には2つのファイルを有効にする必要があります。 ライブラリパスの「win32com.dll」 ファイルと、[system.getProperty("java.home")] によって返されるディレクトリの 「lib」 サブディレクトリ に配置された 「javax.comm.properties」 プロパティファイルです。
自分の 「wrapper.conf」 ファイルが [JAVA_HOME] 環境変数によって指定されているものとは異なる JVM を使うように設定されている場合、 このような問題が発生します。 自分の 「wrapper.conf」 ファイルに下記のように [wrapper.java.command] プロパティで正しく設定されてた JVM を利用していることを確認してください。
wrapper.java.command=%JAVA_HOME%/bin/java
Wrapper の導入前と導入後(インテグレーション後)の Java アプリケーションの動作環境で唯一の違いは、前にはスタートアップ時に JVM によって直接的にアプリケーションのメインメソッドが呼び出されていたことです。 今では、[WrapperSimpleApp]ヘルパークラス、あるいは [WrapperStartStopApp]ヘルパークラスを 利用していると想定すると、 JVM は、まず始めにクラスのメインメソッドを呼び出し、その後 Wrapper が初期化してから アプリケーションのメインメソッドを呼び出します。
これは、セキュリティマネージャーを利用している際に、問題を引き起こすことがあります。 その理由は、Java セキュリティマネージャーがコールスタックを検索して、アクセスを許可する前に、各クラスやメソッドに保護されたコードを呼び出す権利が与えられてることを確認しているためです。 Wrapper のクラスがコールスタックを終了して特権を与えられていないと、セキュリティ例外を受けることになります。
ポリシーファイルに次の内容を追加して、 「wrapper.jar」 にアクセス権を付与してみてください。 通常であれば、この種の問題は改善されるはずです。
// Give Wrapper classes full permissions grant codeBase "file:../lib/wrapper.jar" { permission java.security.AllPermission; };
一部の Java サービスアプリケーションでは、 「Windows上でユーザーがログアウトすると、Java プロセスを終了してしまう」 という問題がたまにあります。 Wrapper は、初代リリースの時点からこの問題に影響されることなく、適切に対処しています。
Wrapper の Java 側は、これを正しく動かすために、ネイティブライブラリ(Windows:「wrapper.dll」、Linux/UNIX:「libwrapper.so」)を必要としています。 ネイティブライブラリは、JVM プロセスに送信されるすべてのシステムシグナルをトラップし、適切に処理する役割を担います。 Java アプリケーションによっては、 [WrapperListener] インターフェイスの [controlEvent] メソッドを実装することで、これらのシグナルの取り扱いを可能にする場合もあります。
ユーザーのログオフ時に、Wrapper によって JVM が再起動されるという問題に悩んでいる場合、 ライブラリが読み込みされていることを確認してください。 もし読み込みされていない場合、WrapperManager の初期化中に、警告メッセージが JVM 出力に表示されます。
Wrapper がコンソールアプリケーションとして、またはサービスとして動作している間に、 ユーザーがログアウトすると何が起きるかの例は、ドキュメンテーションのTestWrapper サンプルアプリケーションの例のセクションを参照ください。
Windows システムの場合、「wrapper.conf」 ファイル の [wrapper.ntservice.process_priority] プロパティ を設定することで優先度を設定できます。 詳しくは、コンフィギュレーションの概要 をご覧ください。
UNIX システムの場合、優先度設定のおススメの方法は、Wrapper 起動時に、 ご自分のシェルスクリプトにある 「nice」 コマンドを使うことです。 Wrapper に同梱されているスクリプト例では、どのようにすればいいかを説明しています。 「nice」の使い方についての詳細は、 「man nice」 あるいは、「info nice」 をご覧ください。
デフォルトでは、Wrapper は JVM のユーザーディレクトリを、 Windows の 「wrapper.exe」 ファイルのある場所、または UNIX システムの「Wrapper シェルスクリプト」のある場所に設定します。 れにより、アプリケーション内で確実に相対パスを使えるようにします。 ユーザーディレクトリは JVM が起動する場所に依存するため、通常これは可能ではありません。
相対パスを利用することで、いかなるディレクトリ内へでもアプリケーションを解凍し、 確実に動かすことができるので、非常に簡単にアプリケーションをインストールできるようになります。
デフォルト以外の場所にユーザーディレクトリを設置する必要があるケースもあります。 その場合には、 [wrapper.working.dir] プロパティを設定することで変更が可能です。
重要 - 余計なことで頭を悩ませる無駄な時間を削減するためにも、変更操作に入る前に [作業ディレクトリー] のプロパティ説明を十分に読んでください。
Windows で複数の Wrapper を動かしている時、タスクマネージャーには、 全てのインスタンスが 「wrapper.exe」 や 「java.exe」 と表示されているため、 どれがどのアプリケーションなのか識別するのは困難です。 Windows セキュリティ上の理由から、Wrapper に表示名を変更する機能を実装することは不可能です。
この回避策として、ややハッキングっぽい方法ですが、効果的です。
Windows タスクマネージャーを見ると、どの実行ファイルが動作しているのか、簡単に確認することができます。
「wrapper.conf」ファイルで、[wrapper.pidfile] プロパティや、 [wrapper.java.pidfile] プロパティを設定することもできます。 そうすると、pid を含むファイルが作成されます。 これらの pid は、タスクマネージャに表示されている pid と比較することができます。 プロセス pid を表示するように、タスクマネージャーの設定を変更する必要がありますのでご注意ください。
Windows:
[wrapper.ntservice.account]プロパティを設定することで、特定のユーザーとして Wrapper を動かすことができます。 その説明を熟読してからサービスを再インストールしてください。
Unix:
デフォルトでは、Unix デーモンは root ユーザーで実行されます。 これは通常、かなり安全であり、アプリケーションをサービスとして起動して実行するための最も簡単な方法です。
ただし、システムのセキュリティをさらに最適化するには、サービスを実行するための専用ユーザーを作成することが推奨されます。 理想的には、このユーザーは Wrapper と Java アプリケーション ファイルのみにアクセスでき、 他のユーザーはこれらのファイルにアクセスできないようにする必要があります。
UNIX 上では、Wrapper シェルスクリプト 「src/bin/App.sh.in」(Wrapper の旧バージョンのファイル名:「sh.script.in」)で「RUN_AS_USER」変数を設定します。 これは、サービスとして実行する場合とコンソールアプリケーションとして実行する場合の両方で使用されます。 ただし、既存のサービスのユーザーを変更する場合は、「RUN_AS_USER」変数を変更した後にサービスを再インストールする必要があります。
「RUN_AS_USER」が設定されている場合、Wrapper プロセスが開始されるとユーザーが変更されます。 つまり、シェルスクリプトを実行している現在のユーザーには、ユーザーを変更する権限が必要です。
重要:(「chown」コマンドと「chmod」コマンドを使用して) Wrapper ファイルと、Java アプリケーションが使用するライブラリまたはファイルの権限を適切に調整することを忘れないでください 。 ほとんどの場合、新しく設定されたユーザーがファイルの所有者になります。複数のサービスが単一の Wrapper インストールを使用するシナリオでは、グループの権限を定義することもできます。
もし、Java アプリケーションが Windows サービスとして動作しているならば、 それは実際には VisualVM を起動しているユーザーと同じコンテキスト/セッションで動作していません。 従って、デフォルトで、VisualVM は Java アプリケーションを見つけることができません。
Windows XP までは、Windows サービス用のゆるいセキュリティポリシーによって、 次のステップのように、かなり簡単に解決を可能にしていました。
JVM が開始している時点で、JVM はそのプロセスとフック情報を環境変数 「%TMP%」 で指定された配置場所へを書き込んでいます。 (こちらを含む)一部の環境変数が各ユーザー用に別々に定義されていることを念頭に置いておいてください。 そのため、サービスと VisualVM が実行されているコンテキストでは、この環境変数に同じ値を使用する必要があります。
set.TMP=C:\tmp
その後、サービスを(再)起動してください。 次に、ここでコンソールを開始して、「TMP」 環境変数を上記のコンフィギュレーションファイルで指定した値と同じ値に設定してください。
set TMP=C:\tmp C:\Program Files\...\jvisualvm.exe
VisualVM は Java プロセスを一覧にすることができるはずです。
Windows XP までは Windows 版用に上記が動作していましたが、Windows Vista/7(さらに後続版)は、セキュリティ対策が厳格化されているため、 ほとんど誰にも許可しないでしょう。したがって、これを解決する唯一の方法は、JMX リモートモニタリング設定を使用することです(必要要件:最低でも Java 1.5)。
wrapper.java.additional.N=-Dcom.sun.management.jmxremote.port=XXXX wrapper.java.additional.N=-Dcom.sun.management.jmxremote.ssl=false wrapper.java.additional.N=-Dcom.sun.management.jmxremote.authenticate=false
[wrapper.java.additional.<n>]プロパティの「N」には未使用の番号を使用し、 「XXXX」 をマシン上の未使用のポート番号に置き換えてください。 VisualVM から、「ファイル」 → 「JMX 接続を追加 」を選択してください。 「接続」欄に「localhost:XXXX」と入力してください (XXXX は conf ファイルで割り当てたポートです)。
JMX モニタリングやマネジメントについて、さらに詳しくは、 JMX コントロール ページ をご覧いただくか、あるいは、 オラクルドキュメンテーション(英文)をご確認ください。
自動化ツールによって仮想マシンが頻繁に削除および作成される環境では、(MAC アドレスに基づく)HostId がライセンス キーに設定されているものと異なるとすぐに Wrapper が動作を停止します。 その場合、ライセンスの所有者はライセンスキーを手動でリセットする必要があります。これにより、仮想マシンを作成するための自律プロセスが中断されます。 ご利用中の仮想化ツールによっては、仮想マシンに固定の MAC アドレスを設定できます。 常に同じ MAC アドレスを使用することで、Wrapper はライセンスキーのエラーなく、確実に開始できます。
次のドキュメンテーションをご参照ください。