NSSM
v2.25
NSSMは、SRVANYとCygrunSRVに似たサービスヘルパープログラムです。 NTサービスとして任意のアプリケーション（コンソールなど）を起動することができ、何らかの理由で失敗した場合にサービスを再起動します。
NSSMには、グラフィカルサービスインストーラーとリムーバーもあります。
これはNSSMのフォークです
ここでリリースで見つけることができるバイナリファイル
元のコード：https：//git.nssm.cc/nssm/nssm by iain patterson
ドキュメント：使用法、コマンド
以下の使用法では、プログラムの引数は、角度ブラケットおよび/または四角い括弧で書かれている場合があります。つまり、適切な文字列を挿入する必要があり、[]は文字列がオプションであることを意味します。以下の例を参照してください...
どこにでも表示されることに注意してください。サービスの表示名を代用することができます。
サービスをインストールするには、実行します
nssm install <servicename>
実行するアプリケーションへのフルパスと、そのアプリケーションに渡すコマンドラインオプションを入力するように求められます。
System Service Manager（Services.MSC）を使用して、起動方法やデスクトップインタラクションなどの高度なサービスプロパティを制御します。 NSSMは後でこれらのオプションをサポートする場合があります...
サービスをインストールするには、実行します
nssm install <servicename> <application> [<options>]
NSSMは、指定されたオプションを使用して名前付きアプリケーションを実行するサービスをインストールしようとします（指定した場合）。
スペースが含まれている場合は、「引用」のパスを囲むことを忘れないでください！
オプションに引用符を含めたい場合は、「引用」を「引用」する必要があります。
NSSMは、スタート信号を送信するときにレジストリにリストされているアプリケーションを起動し、停止信号を送信するときに終了します。これまでのところ、srvanyによく似ています。しかし、NSSMは非潜水型サービスマネージャーであり、アプリケーションが死亡した場合/時に行動を起こすことができます。
あなたからの構成がないため、NSSMは、アプリケーションが死んだことに気付いたが、停止信号を送信しなかった場合、再起動しようとします。 NSSMは、サービスが正常に開始されるか、停止信号を送信するまで、各試行の間で一時停止し、試行を続けます。
NSSMは、サービスが最大4分までタイムリーに開始できない場合、その後の再起動試行の間にますます長い時間を一時停止します。これは、失敗したアプリケーションを何度も繰り返し開始しようとする過剰な量のCPU時間を消費することはありません。障害の原因を特定し、待機したくない場合は、Windowsサービスコンソール（サービスが一時停止状態で表示される場所）を使用してNSSMに連続信号を送信すると、数秒以内に再試行できます。
デフォルトでは、NSSMは「タイムリーな方法」を1500ミリ秒以内に定義しています。 hklm system currentControlset services <Services> parameters appthrottleのレジストリのreg_dword値としてmillisecondsの数を設定することにより、サービスのしきい値を変更できます。
あるいは、NSSMは、AppThrottleで指定された時間に正常に実行された場合でも、アプリケーションを再起動しようとする前に、構成可能な時間の間一時停止できます。 NSSMは、再起動を試みる前に待機するミリ秒数について、hklm system currentControlset services <survice> parameters parameters apprestartDelayでreg_dword値を参照します。 AppRestArtDelayが設定され、アプリケーションがスロットリングの対象となると判断された場合、NSSMは構成された再起動遅延と計算されたスロットル期間のどちらかより長い方のサービスを一時停止します。
AppRestartDelayが欠落または無効な場合、スロットリングのみが適用されます。
NSSMは、hklm system currentControlset services <Services> parameters appExit for string（reg_expand_sz）値の下のレジストリを表示します。たとえば、アプリケーションがコード1で終了した場合、NSSMは「1」と呼ばれるAppExitの下で文字列値を探します。システムイベントログに相談することにより、アプリケーションのExitコードを見つけることができます。 NSSMは、アプリケーションが終了すると終了コードをログにします。
レジストリで見つかったデータに基づいて、NSSMは次の3つのアクションのいずれかを取得します。
値データが「再起動」の場合、NSSMは上記のようにアプリケーションを再起動しようとします。これがデフォルトの動作です。
値データが「無視」の場合、NSSMはアプリケーションを再起動しようとはしませんが、それ自体の実行を続けます。これは、srvanyの（通常望ましくない）動作をエミュレートします。 Windows Servicesコンソールは、アプリケーションが終了しているにもかかわらず、サービスがまだ実行されていると表示されます。
値データが「終了」の場合、NSSMは優雅に終了します。 Windowsサービスコンソールは、停止したサービスを表示します。サービスリカバリをより細かい制御を提供したい場合は、このコードを使用して、障害アクションを手動で編集する必要があります。 Vistaの前のWindowsバージョンは、そのような出口が失敗であるとは見なされないことに注意してください。 Windowsの古いバージョンでは、代わりに「自殺」を使用する必要があります。
値データが「自殺」の場合、NSSMはサービスマネージャーに通知することなくクラッシュと終了をシミュレートします。このオプションは、サービスリカバリアクションを適用する前のVistaシステムにのみ使用する必要があります。監視対象のアプリケーションがコード0で終了する場合、NSSMは、Exitコード0のレジストリキーを明示的に構成する場合にのみ自殺の要求を尊重することに注意してください。デフォルトアクションのみが自殺に設定されている場合、NSSMは代わりに優雅に終了します。
NSSMは、管理されたアプリケーションの優先度クラスを設定できます。 NSSMは、reg_dwordエントリApppriorityのhklm system currentControlset services <Services> パラメーターの下のレジストリを参照します。有効な値は、SetPriorityClass（）に引数に対応しています。 apppriority（）が欠落または無効な場合、アプリケーションは通常の優先度で起動されます。
NSSMは、管理されたアプリケーションのCPUアフィニティを設定できます。 NSSMは、reg_szエントリアッピニティのhklm system currentControlset services <Services> パラメーターの下のレジストリを調べます。ゼロインデックスされたプロセッサIDのコンマ分離されたリストを指定する必要があります。オプションでダッシュでさまざまなプロセッサを指定できます。文字列には他の文字が許可されていません。
たとえば、最初を指定するには。 2番; 3番目と5番目のCPUでは、適切なアッピニティは0〜2,4です。
Appaffinityが欠落または無効な場合、NSSMは特定のCPUへのアプリケーションを制限しようとしません。
NSSMの64ビットバージョンは、この方法で最大64 CPUを構成し、32ビットバージョンは64ビットウィンドウで実行している場合でも32 CPUのマキシウムを構成できることに注意してください。
サービスを停止すると、NSSMは監視対象のアプリケーションを殺すいくつかの異なる方法を試みます。
最初のNSSMは、Control-Cイベントを生成し、アプリケーションのコンソールに送信しようとします。バッチスクリプトまたはコンソールアプリケーションは、イベントを傍受し、優雅にシャットダウンする場合があります。 GUIアプリケーションにはコンソールがなく、この方法に応答しません。
第二に、NSSMはアプリケーションによって作成されたすべてのウィンドウを列挙し、wm_closeメッセージを送信し、優雅な出口を要求します。
第三に、NSSMはアプリケーションによって作成されたすべてのスレッドを列挙し、wm_quitメッセージを送信し、優雅な出口を要求します。すべてのアプリケーションのスレッドにメッセージキューがあるわけではありません。この方法に応答しないもの。
最後に、NSSMはTerminateProcess（）を呼び出して、オペレーティングシステムがアプリケーションを強制的に終了することを要求します。 terminateprocess（）をトラップまたは無視することはできないため、ほとんどの場合、申請は殺されます。ただし、終了する前にTidyUp操作を実行する機会があるという保証はありません。
上記の方法のいずれかまたはすべてが無効になる場合があります。 NSSMは、hklm system currentControlset services <Services> parameters appstopmethodskipレジストリ値を探します。
AppStopMethodskipに1が含まれている場合、Control-Cイベントは生成されません。 AppStopmethodskipに2が含まれている場合、WM_Closeメッセージは投稿されません。 AppStopmethodskipに4が含まれている場合、WM_QUITメッセージは投稿されません。 AppStopmethodskipに8が含まれている場合、TerminateProcess（）は呼び出されません。
たとえば、アプリケーションがControl-Cイベントに応答せず、スレッドメッセージキューがないことを知っていた場合、AppStopMethodSkipを5に設定でき、NSSMはそれらのメソッドを使用してアプリケーションを停止しようとしません。
AppStopmethodskipの値に8を含めるときは、細心の注意を払ってください。 NSSMがTerminateProcess（）を呼び出さない場合、サービスが停止したときにアプリケーションが終了しない可能性があります。
デフォルトでは、NSSMは、次の方法に進む前に、上記の各方法に1500ミリ秒のプロセスを応答できるようにします。タイムアウトは、hklm system currentControlset Services <Services> パラメーターの下でレジストリにREG_DWORDエントリを作成することにより、1つのメソッドベースで構成できます。
AppStopMethodConsole AppStopStopStopMethodWindow AppStopStopStopSodThreads
各値は、待機するミリ秒数に設定する必要があります。タイムアウトはアプリケーションのプロセスツリーの各プロセスに適用されるため、アプリケーションが複数のサブプロセスを生成した場合、実際のシャットダウンまでの実際の時間はすべての構成されたタイムアウトの合計よりも長くなることに注意してください。
上記の停止方法をアプリケーションのプロセスツリーのすべてのプロセスに適用し、元のアプリケーションプロセスにのみ適用するために、HKLM System CurrentControlset Services <Services> Parameters AppKillProcessTreeレジストリ値を設定します。
デフォルトでは、NSSMはコンソールウィンドウを作成して、ユーザー入力を読み取ることができるアプリケーションがそうすることができるようにします - サービスがデスクトップと対話することを許可されます。
コンソールの作成は、整数（reg_dword）hklm system currentControlset services <services> parameters appnoconsoleレジストリ値を設定することで抑制できます。
NSSMは、ManagedアプリケーションのI/OをCreateFile（）によって開くことができる任意のパスにリダイレクトできます。これにより、たとえば、コンソールに書き込み、シリアルポートからの入力のみを受け入れるアプリケーションのログ出力をキャプチャできます。
NSSMは、createFile（）に対応するキーのhklm system currentControlset services <Services> パラメーターの下のレジストリを調べます。すべてオプションです。特定のストリームにパスが与えられない場合、リダイレクトされません。パスが指定されているが、他の値のいずれかが省略されている場合、賢明なデフォルトを受信します。
appstdin：入力を受信するパス。 AppStDout：出力を受信するパス。 appstderr：エラー出力を受信するパス。
createFile（）のパラメーターは、「appstdinsharemode」、「appstdincreationDisposition」、および「appstdinflagsandattributes」値を提供しています（Stdoutとstderrについて）。
一般的に、サービスをその出力をログに記録する場合は、AppstDoutとAppStderrを同じパス、例：C： Users public service.logに設定すると、動作するはずです。ただし、サービスを実行しているユーザーがパスにアクセスできる必要があることを忘れないでください。
I/Oリダイレクトを使用する場合、NSSMはSTDOUTおよび/またはSTDERRを開く前に既存の出力ファイルを回転させることができます。既存のファイルは、ファイルの最後の書き込み時間に基づいて、ミリ秒の精度に基づいてサフィックスで名前が変更されます。たとえば、ファイルnssm.logは、NSSM-20131221T113939.457.logに回転する場合があります。
NSSMは、回転の発生方法を制御するREG_DWORDエントリのHKLM System CurrentControlset Services <Services> パラメーターの下のレジストリを調べます。
ApproTateFilesが欠落または0に設定されている場合、回転は無効になります。ゼロ以外の値は、回転を有効にします。
ApprotateseCondsがゼロでない場合、最後の書き込み時間が過去の特定の秒数よりも少ない場合、ファイルは回転しません。
ApprotateBytesがゼロではない場合、特定のバイト数よりも小さい場合、ファイルは回転しません。 64ビットファイルサイズは、ApprotateByteshighの非ゼロ値を設定することで処理できます。
ApprotatedElayがゼロでない場合、NSSMは回転後に与えられたミリ秒の数を一時停止します。
AppStDoutCopyAndTruncateまたはAppStderRCopyAndTruncateがゼロでない場合、STDOUT（またはSTDER）ファイルは、最初にファイルのコピーを取得してから元のファイルをゼロサイズに切り捨てることによって回転します。これにより、NSSMは他のプロセスによって開いているファイルを回転させ、通常のMoveFile（）が成功するのを防ぎます。ファイルが大きい場合はコピープロセスに時間がかかり、元のファイルの2倍のディスクスペースを一時的に消費する場合があります。また、ログファイルを読み取るアプリケーションは、ファイルサイズが変更されたことに気付かない場合があることに注意してください。このオプションをApprotatedElayと組み合わせて使用すると、その場合に役立つ場合があります。
回転は、ファイルを開くために使用されるcreatefile（）パラメーターとは無関係です。 NSSMが他の方法でそれらを追加または交換したかどうかに関係なく、それらは回転します。
NSSMは、サービスの実行中に構成されたサイズのしきい値を押すファイルを回転させることもできます。さらに、コマンドを実行することにより、オンデマンド回転をトリガーできます
nssm rotate <servicename>
オンデマンドの回転は、ApprotateBytesの値に関係なく、次のデータラインが管理されたアプリケーションから読み取られた後に発生します。アプリケーションが特に冗長でない場合、回転はしばらく発生しない可能性があることに注意してください。
オンラインおよびオンデマンドの回転を有効にするには、ApproTateOnlineを非ゼロ値に設定します。
オンラインローテーションでは、NSSMがアプリケーションのI/Oをインターセプトし、そのために出力ファイルを作成する必要があることに注意してください。これは、アプリケーションを起動する前に単にI/Oストリームをリダイレクトするよりも複雑でエラーが発生しやすいものです。したがって、オンライン回転はデフォルトでは有効になりません。
出力をリダイレクトする場合、NSSMは各出力ラインをMillisecond Precision Timestampでプレフィキをかけることができます。
2016-09-06 10:17:09.451 Pipeline main started
タイムスタンプのプレフィックスを有効にするには、AppTimestamplogをゼロ以外の値に設定します。
プレフィックスは、stdoutとstderrの両方に適用されます。プレフィックスは、オンラインローテーションと同じようにアプリケーションのI/Oを傍受する必要があります。ログの回転とタイムスタンプのプレフィックスが両方が有効になっている場合、回転はオンラインになります。
NSSMは、管理されたアプリケーションの環境を交換または追加できます。 2つの多値文字列（reg_multi_sz）レジストリ値は、hklm system currentControlset Services <Services> パラメーターの下で認識されます。
Appenvironmentは、サービスの環境をオーバーライドする環境変数のリストを定義します。 AppenVironmentExtraは、サービスの環境に追加される環境変数のリストを定義します。
リスト内の各エントリは、key = valueの形式でなければなりません。値を省略することは可能ですが、=シンボルは必須です。
AppenvironmentとAppenvironmentExtraの両方にリストされている環境変数は、通常の拡張の対象となるため、たとえば、Appenvironmentextraで「PATH = C： bin;％PATH％」を設定することにより、システムパスを更新することができます。変数は表示される順序で拡張されるため、1つの変数の値を別の変数に含めたい場合は、最初に依存関係を宣言する必要があります。
控えめで定義された変数は既存の環境を上書きするため、以前に定義されていた変数を参照することはできません。
たとえば、次の控えめブロック：
PATH=C:WindowsSystem32;C:Windows
PATH=C:bin;%PATH%
予想どおり、「c： bin; c： windows system32; c： windows」のパスになります。
一方、次の控えめブロックは次のとおりです。
PATH=C:bin;%PATH%
c： binのみを含むパスが発生し、おそらくアプリケーションが開始されません。
ほとんどの人は、appenvironmentextraのみを使用したいと思うでしょう。 srvanyは控訴環境のみをサポートしています。
バージョン2.25の時点で、NSSMは他のレジストリ値を読み取る前に、AppenvironmentとAppenvironmentExtra自体を分析します。その結果、アプリケーション、AppDirectory、およびその他のパラメーターのカスタム環境変数を参照できるようになりました。
すべてのWindowsサービスは、HLKM System CurrentControlset Services <Services> 環境という名前のマルチValued String（reg_multi_sz）レジストリ値を作成することにより、追加の環境変数に合格できます。
この環境ブロックの内容は、サービスが開始される前にシステム環境にマージされます。
ただし、マージされた環境は、処理される前にアルファベット順にソートされることに注意してください。これは、実際には、サービスに渡された環境が％dir％を定義するまでに％プログラムファイル％を定義していないため、環境ブロック内のdir =％プログラムファイル％を設定できないことを意味します。 appenvironmentextraで定義された環境変数は、この制限に悩まされていません。
バージョン2.25の時点で、NSSMは次のようなコマンドを使用して環境ブロックを取得および設定できます。
nssm get <servicename> Environment
NSSMサービスだけでなく、環境ブロックがすべてのWindowsサービスで利用できることを繰り返し繰り返す価値があります。
環境NSSMがアプリケーションに合格することは、さまざまなレジストリ値の構成方法によって異なります。次のフローでは、環境がどのように変更されるかを説明しています。
デフォルトでは、サービスはシステム環境を継承します。
環境が定義されている場合：環境の内容が環境に統合されます。
parameters appenvironmentが定義されている場合：サービスは、Appenvironmentで指定された環境を継承します。
parameters appenvironmentextraが定義されている場合：appenvironmentextraの内容が環境に追加されます。
Appenvironmentは、システム環境とマージされた環境ブロックをオーバーライドすることに注意してください。また、AppenvironmentExtraが定義されている場合はスタートアップ環境に追加されることが保証されていることに注意してください。
NSSMは、アプリケーションイベントに応じてユーザー構成コマンドを実行できます。これらのコマンドは、以下の「フック」と呼ばれます。
すべてのフックはオプションです。実行されるフックは、サービス用に構成された環境で起動されます。 NSSMは、追加の変数を環境に配置します。これは、フックがどのように、そしてなぜ呼び出されたかを学ぶためにクエリすることができます。
フックはイベントとアクションに分類されます。いくつかのフックは同期して実行され、一部は非同期に実行されます。 *アスタリスクが付いたフックは同期して実行されます。 NSSMは、作業を継続する前にこれらのフックが完了するのを待ちます。ただし、すべてのフックは、非同期に実行されているかどうかにかかわらず、殺害される期限の対象となることに注意してください。
イベント：開始 - サービスの開始が要求されたときにトリガーされます。 *アクション：NSSMがアプリケーションを起動しようとする前に、事前に呼び出されます。アクション：投稿 - アプリケーションが正常に開始された後に呼び出されます。
イベント：停止 - サービスが停止するように要求されたときにトリガーされます。 *アクション：NSSMがアプリケーションを殺そうとする前に事前に呼び出されます。
イベント：終了 - アプリケーションが終了するとトリガーされます。 *アクション：投稿-NSSMがアプリケーションをクリーンアップした後に呼び出されました。
イベント：回転 - オンラインログ回転が要求されたときにトリガーされます。 *アクション：NSSMがログを回転させる前に呼び出されます。アクション：投稿-NSSMがログを回転させた後に呼び出されます。
イベント：パワーアクション：変更 - システムパワーステータスが変更されたときに呼び出されます。アクション：履歴書 - システムがスタンバイから再開されたときに呼び出されます。
ストップ/ポストフックはないことに注意してください。これは、サービスシャットダウンリクエストに応じてそうしたかどうかに関係なく、アプリケーションが終了するときに出口/投稿が呼び出されるためです。 STOP/PREは、優雅なシャットダウンの試みの前にのみ呼び出されます。
NSSMは、環境変数NSSM_Hook_versionを正の数に設定します。フックは、数の値をチェックして、他の環境変数が利用できるかを判断できます。
nssm_hook_versionが1以上の場合、これらの変数が提供されます。
NSSM_EXE- NSSM自体へのパス。 NSSM_CONFIGURATION -NSSM実行可能ファイルの情報を作成します。たとえば、64ビットデバッグ。 NSSM_Version- NSSM実行可能ファイルのバージョン。 NSSM_BUILD_DATE -NSSMのビルド日。 NSSM_PID-実行中のNSSM実行可能ファイルのプロセスID。 NSSM_DEADLINE -NSSMがまだ実行されている場合、NSSMがフックを殺した後、ミリ秒の締め切り数。 NSSM_SERVICE_NAME-NSSMが管理するサービスの名前。 nssm_service_displayname-サービスの名前を表示します。 nssm_command_line-アプリケーションの起動に使用されるコマンドライン。 NSSM_APPLICATION_PID-プライマリアプリケーションプロセスのプロセスID。プロセスが実行されていない場合は空白になる可能性があります。 NSSM_EVENT-フックをトリガーするイベントクラス。 NSSM_ACTION-フックをトリガーするイベントアクション。 NSSM_TRIGGER-フックをトリガーするサービス制御。フックがサービスコントロールによってトリガーされていない場合、Exit/Postなどの空白になる可能性があります。 NSSM_LAST_CONTROL- NSSMが処理する最後のサービスコントロール。 nssm_start_requested_count-アプリケーションが開始するように要求された回数。 NSSM_START_COUNT-アプリケーションが正常に開始される回数。 NSSM_THROTTLE_COUNT-アプリケーションの回数は、スロットル期間未満で実行されました。成功した開始時またはサービスが明示的に容認されていないときにゼロにリセットします。 nssm_exit_count-アプリケーションが終了した回数。 NSSM_EXITCODE-アプリケーションのコードを終了します。アプリケーションがまだ実行されている場合、またはまだ開始していない場合は空白になる可能性があります。 NSSM_RUNTIME-NSSM実行可能ファイルが実行されているミリ秒数。 NSSM_APPLICATION_RUNTIME-最終開始以来、アプリケーションが実行されているミリ秒数。アプリケーションがまだ開始されていない場合は、空白になる可能性があります。
NSSMの将来のバージョンは、より多くの環境変数を提供する場合があります。この場合、NSSM_Hook_versionはより高い数に設定されます。
フックは、フックアクションにちなんで名付けられたレジストリに文字列（reg_expand_sz）値を作成し、hklm system currentcontrolset services <services> parameters appevents <event>の下に配置することによって構成されます。
たとえば、サービスは、appevents power resumeを次のように設定することにより、システムがスタンバイから再開されたときに再起動するように構成できます。
%NSSM_EXE% restart %NSSM_SERVICE_NAME%
コマンドラインにフックを設定するには、使用します
nssm set <servicename> AppEvents <event>/<action> <command>
Start/Pre Hookが99のExitコードを返す場合、NSSMはアプリケーションの起動を中止することに注意してください。
サービスは通常、次の順序でフックを実行します。
開始/事前開始/ポストストップ/プレの出口/ポスト
アプリケーションがクラッシュし、NSSMによって再起動された場合、順序は次のとおりです。
Start/Pre Start/Post Exit/Post Start/Pre Start/Post Stop/Pre Exit/Post
NSSMがstdoutまたはstderrをリダイレクトしている場合、実行するフックの出力をリダイレクトするように構成できます。その機能を有効にするために、AppRediRecthooksを1に設定します。もちろん、フックはNSSMとは無関係に独自のI/Oをリダイレクトできます。
NSSMは、それらをインストールするために使用される同じGUIで既存のサービスの設定を編集できます。走る
nssm edit <servicename>
GUIを育てます。
NSSMは、NSSM自体を実行しているサービス以外のサービスに限られた編集機能を提供します。 NSSMが上記のアプリ*レジストリ設定を持たないサービスを編集するように求められた場合、GUIはサービス表示名や説明などのシステム設定のみを編集することができます。
NSSMは、コマンドラインから個々のサービスパラメーターを取得または設定できます。一般に、構文は次のとおりですが、例外については以下を参照してください。
nssm get <servicename> <parameter>
nssm set <servicename> <parameter> <value>
パラメーターは、デフォルト値にリセットすることもできます。
nssm reset <servicename> <parameter>
NSSMによって認識されるパラメーター名は、上記のレジストリエントリ名、例えばAppDirectoryと同じです。
NSSMは、NSSM自体を実行しているサービス以外のサービスに限られた編集機能を提供します。認識されるパラメーターは次のとおりです。
説明：サービスの説明。 displayName：サービスディスプレイ名。環境：サービス環境の融合。 ImagePath：サービス実行可能ファイルへのパス。 ObjectName：サービスを実行するユーザーアカウント。名前：サービスキー名。開始：サービススタートアップタイプ。タイプ：サービスタイプ。
これらは、サービスのキーHKLM System currentControlset Services <Services>の下のレジストリ値に対応しています。
NSSMは、スペースでコマンドラインに渡されたすべての引数を連結して、設定する値を形成することに注意してください。したがって、次の2つの呼び出しは同じ効果をもたらします。
nssm set <servicename> Description "NSSM managed service"
nssm set <servicename> Description NSSM managed service
Appenvironment、AppenvironmentExtra、および環境パラメーターは、環境を照会するときに追加の議論を認識します。次の構文は、サービス用に構成されたすべての追加の環境変数を印刷します
nssm get <servicename> AppEnvironmentExtra
一方、以下の構文は、環境ブロックで構成されている場合はClassPath変数の値のみ、または構成されていない場合は空の文字列のみを印刷します。
nssm get <servicename> AppEnvironmentExtra CLASSPATH
環境ブロックを設定するとき、各変数は、個別のコマンドライン引数でキー=値ペアとして指定する必要があります。例えば：
nssm set <servicename> AppEnvironment CLASSPATH=C:Classes TEMP=C:Temp
あるいは、キーを +または - シンボルでプレフィックスして、それぞれブロックからペアを追加または削除することができます。
次の2行はクラスパスと温度を設定します。
nssm set <servicename> AppEnvironment CLASSPATH=C:Classes
nssm set <servicename> AppEnvironment +TEMP=C:Temp
キーが既に存在している場合、指定 +キーは、キーの順序を維持しながら値をオーバーライドします。
nssm set <servicename> AppEnvironment +CLASSPATH=C:NewClasses
次の構文は、ブロックから単一の変数を削除し、他の変数を所定の位置にしたままにします。
nssm set <servicename> AppEnvironment -TEMP
-key = valueを指定すると、既存の値が一致する場合にのみ変数が削除されます。
次の構文では、temp = c： tempを除去しません
nssm set <servicename> AppEnvironment -TEMP=C:WorkTemporary
+および - シンボルは、環境変数の有効な文字です。構文：key = valueはkey = valueに相当し、+/-から始まる変数を設定するために使用できます。
nssm set <servicename> AppEnvironment :CLASSPATH=C:Classes
nssm set <servicename> AppEnvironment +TEMP=C:Temp
AppExitパラメーターには、Exitコードを取得または設定するための追加の引数が必要です。デフォルトのアクションは、文字列のデフォルトで指定できます。
たとえば、サービスのデフォルトの終了アクションを取得するには、実行する必要があります
nssm get <servicename> AppExit Default
Exitコード2でアプリケーションが終了したときに終了アクションを取得するには、実行する
nssm get <servicename> AppExit 2
指定された出口コードに対して明示的なアクションが構成されていない場合、NSSMはデフォルトの出口アクションを印刷することに注意してください。
設定するには、出口コードが2のexitコードでアプリケーションが終了したときに停止するようにサービスを構成するには、実行します
nssm set <servicename> AppExit 2 Exit
AppPriorityパラメーターは、管理されたアプリケーションの優先度クラスを設定するために使用されます。有効な優先順位は次のとおりです。
realtime_priority_class high_priority_class obs_normal_priority_class normal_priority_class deoder_normal_priority_class idle_priority_class
DepronroupおよびDependonerviceパラメーターは、サービスの依存関係を照会または設定するために使用されます。依存関係を設定する場合、各サービスグループまたはサービスグループ（ +シンボルの前）は、個別のコマンドライン引数で指定する必要があります。例えば：
nssm set <servicename> DependOnService RpcSs LanmanWorkstation
あるいは、依存関係名を +または - シンボルをそれぞれ追加または削除するための +または - シンボルでプレフィックスすることができます。
次の2行は、RPCSとLanmanworkStationに依存関係を設定します。
nssm set <servicename> DependOnService RpcSs
nssm set <servicename> DependOnService +LanmanWorkstation
次の構文は、RPCSSへの依存性を削除します。
nssm set <servicename> DependOnService -RpcSs
厳密に言えば、サービスグループは +シンボルをプレインしている必要があります。グループへの単一の依存関係を指定するには、 +シンボルに：シンボルをプレフィックスできます。
次の行は同等であり、それぞれがnetbiosgroupにのみ依存関係を設定します。
nssm set <servicename> DependOnGroup NetBIOSGroup
nssm set <servicename> DependOnGroup :NetBIOSGroup
nssm set <servicename> DependOnGroup :+NetBIOSGroup
一方、これらの行は既存の依存関係に追加されます。
nssm set <servicename> DependOnGroup +NetBIOSGroup
nssm set <servicename> DependOnGroup ++NetBIOSGroup
名前パラメーターは、設定されているのではなく、照会することのみができます。サービスのレジストリキー名を返します。これは、構文が必要な場所でサービスの表示名を代用できるという事実を利用するかどうかを知るのに役立つかもしれません。
ObjectNameパラメーターには、ユーザー名を設定する場合にのみ追加の引数が必要です。追加の引数は、ユーザーのパスワードです。
ユーザー名を取得するには、実行します
nssm get <servicename> ObjectName
ユーザー名とパスワードを設定するには、実行します
nssm set <servicename> ObjectName <username> <password>
引数の連結規則が引き続き適用されることに注意してください。次の呼び出しは有効であり、期待される効果があります。
nssm set <servicename> ObjectName <username> correct horse battery staple
次のよく知られているユーザー名では、パスワードは必要ありません。使用すると、パスワードパラメーターを省略できます。
"localsystem" aka "system" aka "nt authority system" "localservice" aka "local service" nt authority local service "" networkservice "aka" network service "nt authority ネットワークサービス
開始パラメーターは、サービスの起動タイプをクエリまたは設定するために使用されます。有効なサービススタートアップタイプは次のとおりです。
service_auto_start：ブートでの自動起動。 service_delayed_start：ブートでの起動の遅延。 service_demand_start：マニュアルサービスの起動。 service_disabled：サービスは無効です。
service_delayed_startは、Vistaの前にWindowsのバージョンでサポートされていないことに注意してください。 NSSMは、遅延開始が利用できない場合、サービスを自動スタートアップに設定します。
タイプパラメーターは、サービスタイプをクエリまたは設定するために使用されます。 NSSMは、現在文書化されているすべてのサービスタイプを認識していますが、2つのタイプのいずれかを設定できます。
service_win32_own_process：スタンドアロンサービス。これがデフォルトです。 service_interactive_process：デスクトップと対話できるサービス。
サービスは、LocalSystemアカウントの下で実行される場合にのみインタラクティブとして構成できることに注意してください。インタラクティブサービスを構成する安全な方法は、次のように2つの段階にあります。
nssm reset <servicename> ObjectName
nssm set <servicename> Type SERVICE_INTERACTIVE_PROCESS
NSSMは、初歩的なサービス制御機能を提供します。
nssm start <servicename>
nssm restart <servicename>
nssm stop <servicename>
nssm status <servicename>
nssm statuscode <servicename>
「NSSMステータス」と「NSSMステータスコード」の出力は、サービス状態などのService_runningを表す文字列です。
ステータスが成功した場合、「NSSMステータス」の出口コードは0になります。 Exitコードがゼロでない場合、エラーがありました。
「NSSMステータスコード」の出口コードは、Service_runningの場合、サービス状態の数値となります。ゼロは有効なサービス状態コードではありません。出口コードがゼロの場合、エラーがありました。
NSSMはサービスを削除することもできます。走る
nssm remove <servicename>
サービスを削除します。サービスが削除される前に、確認を求められます。必須システムサービスを削除しないようにしてください...
GUIから確認せずにサービスを削除するには、実行してください
nssm remove <servicename> confirm
必須システムサービスを削除しないようにしてください...
WindowsイベントログへのNSSMログ。イベントログソースとして登録し、ログログのタイプのメッセージごとに一意のイベントIDを使用します。新しいバージョンはイベントタイプを追加する可能性がありますが、既存のイベントIDは変更されません。
NSSMが登録する方法により、イベントビューアーが開いている場合、NSSMのバイナリを交換できない可能性があり、異なる場所からNSSMの複数のインスタンスを実行することは、すべて同じバージョンではない場合は混乱する可能性があることに注意する必要があります。
次のコマンドは、NSSMが管理するすべてのサービスの名前を印刷します。
nssm list
NSSMだけでなく、システム上のすべてのサービスを表示するには、すべてのリストを使用してください。
nssm list all
次のコマンドは、特定のサービスによって開始されたプロセスのプロセスIDと実行可能パスを印刷します。
nssm processes <servicename>
32ビットNSSMがVistaよりも古いバージョンのWindowsを実行している64ビットシステムで実行されている場合、64ビットプロセスのパスを照会できないことに注意してください。
NSSMは、サービスの構成を再現するコマンドをダンプできます。出力をバッチスクリプトに貼り付けて、サービスをバックアップしたり、別のコンピューターに転送したりできます。
nssm dump <servicename>
サービス構成には、コマンドプロンプトから引用または逃げる必要がある文字が含まれている可能性があるため、NSSMは、スクリプトとして実行されるときに正しく動作する出力を生成しようとします。
サービスのコピーを容易にするために、Dumpコマンドは、出力で使用されるサービスの名前を指定する2番目の引数を受け入れます。
nssm dump <servicename> <newname>
ダンプの行は、の構成を表示しながらサービスを参照します。
非現実的なトーナメントサーバーをインストールするには：
nssm install UT2004 c:gamesut2004systemucc.exe server
「ゲーム」ユーザーとしてサーバーを実行するには：
nssm set UT2004 ObjectName games password
ファイルにログにログするようにサーバーを構成するには：
nssm set UT2004 AppStdout c:gamesut2004service.log
To restrict the server to a single CPU:
nssm set UT2004 AppAffinity 0
To remove the server:
nssm remove UT2004 confirm
To find out the service name of a service with a display name:
nssm get "Background Intelligent Transfer Service" Name
NSSM is known to compile with Visual Studio 2008 and later. Older Visual Studio releases may or may not work if you install an appropriate SDK and edit the nssm.vcproj and nssm.sln files to set a lower version number. They are known not to work with default settings.
NSSM will also compile with Visual Studio 2010 but the resulting executable will not run on versions of Windows older than XP SP2. If you require compatiblity with older Windows releases you should change the Platform Toolset to v90 in the General section of the project's Configuration Properties.
Thanks to Bernard Loh for finding a bug with service recovery. Thanks to Benjamin Mayrargue (www.softlion.com) for adding 64-bit support. Thanks to Joel Reingold for spotting a command line truncation bug. Thanks to Arve Knudsen for spotting that child processes of the monitored application could be left running on service shutdown, and that a missing registry value for AppDirectory confused NSSM. Thanks to Peter Wagemans and Laszlo Keresztfalvi for suggesting throttling restarts. Thanks to Eugene Lifshitz for finding an edge case in CreateProcess() and for advising how to build messages.mc correctly in paths containing spaces. Thanks to Rob Sharp for pointing out that NSSM did not respect the AppEnvironment registry value used by srvany. Thanks to Szymon Nowak for help with Windows 2000 compatibility. Thanks to François-Régis Tardy and Gildas le Nadan for French translation. Thanks to Emilio Frini for spotting that French was inadvertently set as the default language when the user's display language was not translated. Thanks to Riccardo Gusmeroli and Marco Certelli for Italian translation. Thanks to Eric Cheldelin for the inspiration to generate a Control-C event on shutdown. Thanks to Brian Baxter for suggesting how to escape quotes from the command prompt. Thanks to Russ Holmann for suggesting that the shutdown timeout be configurable. Thanks to Paul Spause for spotting a bug with default registry entries. Thanks to BUGHUNTER for spotting more GUI bugs. Thanks to Doug Watson for suggesting file rotation. Thanks to Арслан Сайдуганов for suggesting setting process priority. Thanks to Robert Middleton for suggestion and draft implementation of process affinity support. Thanks to Andrew RedzMax for suggesting an unconditional restart delay. Thanks to Bryan Senseman for noticing that applications with redirected stdout and/or stderr which attempt to read from stdin would fail. Thanks to Czenda Czendov for help with Visual Studio 2013 and Server 2012R2. Thanks to Alessandro Gherardi for reporting and draft fix of the bug whereby the second restart of the application would have a corrupted environment. Thanks to Hadrien Kohl for suggesting to disable the console window's menu. Thanks to Allen Vailliencourt for noticing bugs with configuring the service to run under a local user account. Thanks to Sam Townsend for noticing a regression with TerminateProcess(). Thanks to Barrett Lewis for suggesting the option to skip terminating the application's child processes. Thanks to Miguel Angel Terrón for suggesting copy/truncate rotation. Thanks to Yuriy Lesiuk for suggesting setting the environment before querying the registry for parameters. Thanks to Gerald Haider for noticing that installing a service with NSSM in a path containing spaces was technically a security vulnerability. Thanks to Scott Ware for reporting a crash saving the environment on XP 32-bit. Thanks to Stefan and Michael Scherer for reporting a bug writing the event messages source. Thanks to Paul Baxter for help with Visual Studio 2015. Thanks to Mathias Breiner for help with Visual Studio and some registry fixes. Thanks to David Bremner for general tidyups. Thanks to Nabil Redmann for suggesting redirecting hooks' output. Thanks to Bader Aldurai for suggesting the process tree. Thanks to Christian Long for suggesting virtual accounts. Thanks to Marcin Lewandowski for spotting a bug appending to large files. Thanks to Nicolas Ducrocq for suggesting timestamping redirected output. Thanks to Meang Akira Tanaka for suggestion and initial implementation of the statuscode command. Thanks to Kirill Kovalenko for reporting a crash with NANO server. Thanks to Connor Reynolds for spotting a potential buffer overflow. Thanks to foi for spotting a hang with 64 cores.
NSSM is public domain. You may unconditionally use it and/or its source code for any purpose you wish.
