NSSM
v2.25
NSSM ist ein Service -Helfer -Programm ähnlich wie Srvany und Cygrunsrv. Es kann jede Anwendung (z. B. Konsole) als NT -Dienst starten und den Dienst neu starten, wenn er aus irgendeinem Grund fehlschlägt.
NSSM verfügt außerdem über einen grafischen Service -Installationsprogramm und einen Entferner.
Dies ist eine Gabel von NSSM
Binärdateien, die Sie hier in Veröffentlichungen finden
Ursprünglicher Code: https://git.nssm.cc/nssm/nssm von iain patterson
Dokumentation: Verwendung, Befehle
In den folgenden Nutzungsnotizen können Argumente an das Programm in Angle -Klammern und/oder quadratischen Klammern geschrieben werden. bedeutet, dass Sie die entsprechende Zeichenfolge einfügen müssen und [] bedeutet, dass die Zeichenfolge optional ist. Siehe die Beispiele unten ...
Beachten Sie, dass Sie überall erscheint, dass Sie den Anzeignamen des Dienstes ersetzen können.
Um einen Dienst zu installieren, laufen Sie aus
nssm install <servicename>
Sie werden aufgefordert, den vollständigen Pfad in die Anwendung einzugeben, die Sie ausführen möchten, und alle Befehlszeilenoptionen, um an diese Anwendung weiterzugeben.
Verwenden Sie den System Service Manager (Services.MSC), um erweiterte Serviceeigenschaften wie Startmethoden und Desktop -Interaktion zu steuern. NSSM kann diese Optionen zu einem späteren Zeitpunkt unterstützen ...
Um einen Dienst zu installieren, laufen Sie aus
nssm install <servicename> <application> [<options>]
NSSM versucht dann, einen Dienst zu installieren, der die benannte Anwendung mit den angegebenen Optionen ausführt (falls Sie eine angegeben haben).
Vergessen Sie nicht, Wege in "Zitate" einzuschließen, wenn sie Räume enthalten!
Wenn Sie Zitate in die Optionen einbeziehen möchten, müssen Sie die Zitate "" "" "" "" "" "".
NSSM startet die in der Registrierung aufgeführte Anwendung, wenn Sie ihr ein Startsignal senden, und beendet sie, wenn Sie ein Stoppsignal senden. Soweit so sehr wie Srvany. NSSM ist jedoch der nicht saugle Service Manager und kann Maßnahmen ergreifen, wenn die Bewerbung stirbt.
Ohne Konfiguration von Ihnen wird NSSM versucht, sich neu zu starten, wenn festgestellt wird, dass die Anwendung gestorben ist, aber Sie kein Stoppsignal gesendet haben. NSSM wird es weiter versuchen und zwischen jedem Versuch pausieren, bis der Service erfolgreich gestartet wird oder Sie ihm ein Stoppsignal senden.
NSSM wird zwischen den nachfolgenden Neustartversuchen immer länger pausieren, wenn der Service bis zu maximal vier Minuten nicht rechtzeitig beginnt. Dies ist so, dass es nicht immer wieder eine übermäßige Menge an CPU -Zeit verbraucht, um eine fehlgeschlagene Anwendung immer wieder zu starten. Wenn Sie die Ursache des Fehlers identifizieren und nicht warten möchten, können Sie die Windows Service -Konsole (wobei der Dienst in einer Pause angezeigt wird) ein weiteres Signal an NSSM senden und innerhalb weniger Sekunden wiederholen.
Standardmäßig definiert NSSM "zeitnahe Weise" innerhalb von 1500 Millisekunden. Sie können den Schwellenwert für den Dienst ändern, indem Sie die Anzahl der Millisekunden als Reg_DWORD -Wert in der Registrierung unter HKLM System currentControlSet Services <Service> Parameters AppThrottle festlegen.
Alternativ kann NSSM eine konfigurierbare Zeit innehalten, bevor versucht wird, die Anwendung neu zu starten, auch wenn sie erfolgreich für die durch Apphrottle angegebene Zeit ausgeführt wird. NSSM wird den Wert von reg_dword unter HKLM System CurrentControlSet Services <Service> Parameters appentartDelay konsultieren, damit die Anzahl der Millisekunden warten kann, bevor Sie einen Neustart versuchen. Wenn ein Einverständniserteil festgelegt ist und der Antrag für Drosselung unterliegt, pausieren NSSM den Dienst, für den sich die konfigurierte Neustartverzögerung und den berechneten Gasperioden länger länger befindet.
Wenn ein Ehrfurcht von AURTEILDELAY fehlt oder ungültig ist, wird nur Drosselung angewendet.
NSSM wird in der Registrierung unter HKLM System CurrentControlSet Services <Service> Parameter appexit für String (reg_expand_sz) betrachtet, die dem Exit -Code der Anwendung entsprechen. Wenn die mit Code 1 beendete Anwendung beispielsweise NSSM unter Appexit "1" nach einem Zeichenfolgenwert sucht oder, falls er nicht findet, fällt es auf den Wert von Appexit (Standard) zurück. Sie können den Exit -Code für die Anwendung finden, indem Sie das Systemereignisprotokoll konsultieren. NSSM protokolliert den Exit -Code, wenn die Anwendung beendet ist.
Basierend auf den in der Registrierung gefundenen Daten wird NSSM eines von drei Maßnahmen ergreifen:
Wenn die Wertdaten "neu starten" sind, wird NSSM versucht, die oben beschriebene Anwendung neu zu starten. Dies ist das Standardverhalten.
Wenn die Wertdaten "ignorieren" werden, wird NSSM nicht versucht, die Anwendung neu zu starten, sondern wird weiterhin selbst ausgeführt. Dies emuliert das (normalerweise unerwünschte) Verhalten von Srvany. Die Windows Services -Konsole würde den Dienst als noch ausgeführt zeigen, obwohl die Anwendung beendet ist.
Wenn die Wertdaten "Beenden" NSSM sind, wird anmutig beendet. Die Windows Services -Konsole würde den Dienst als gestoppt zeigen. Wenn Sie eine feiner körnige Kontrolle über die Wiederherstellung von Service bieten möchten, sollten Sie diesen Code verwenden und die Fehleraktion manuell bearbeiten. Bitte beachten Sie, dass Windows -Versionen vor Vista einen solchen Ausgang nicht als Fehler betrachten. In älteren Versionen von Windows sollten Sie stattdessen "Selbstmord" verwenden.
Wenn die Wertdaten "Selbstmord" sind, simuliert NSSM einen Absturz und beendet, ohne den Service Manager zu informieren. Diese Option sollte nur für Vor-Vista-Systeme verwendet werden, bei denen Sie eine Dienstleistungsmaßnahme für die Dienstleistungen anwenden möchten. Beachten Sie, dass NSSM, wenn die überwachte Anwendung mit Code 0 beendet wird, nur eine Anfrage an Selbstmord auswirkt, wenn Sie einen Registrierungsschlüssel für den Bezugscode 0 ausdrücklich konfigurieren. Wenn nur die Standardaktion auf Suicide NSSM eingestellt ist, wird stattdessen anmutig beendet.
NSSM kann die Prioritätsklasse der verwalteten Anwendung festlegen. NSSM wird in der Registrierung unter HKLM System CurrentControlSet Services <Service> Parametern für die AppPriority Reg_DWORD einsehen. Gültige Werte entsprechen Argumenten an setPriorityClass (). Wenn AppPriority () fehlt oder ungültig ist, wird die Anwendung mit normaler Priorität gestartet.
NSSM kann die CPU -Affinität der verwalteten Anwendung festlegen. NSSM wird in der Registrierung unter HKLM System CurrentControlSet Services <Service> Parametern für die Appaffinität reg_sz einsehen. Es sollte eine von Kommas getrennte von Null-Indexed-Prozessor-IDs angegeben. Eine Reihe von Prozessoren kann optional mit einem Dash angegeben werden. In der Zeichenfolge sind keine anderen Zeichen erlaubt.
Zum Beispiel um das erste anzugeben; zweite; Dritter und fünfter CPUs, eine angemessene Appaffinität wäre 0-2,4.
Wenn Appaffinity fehlt oder ungültig ist, versucht NSSM nicht, die Anwendung auf bestimmte CPUs zu beschränken.
Beachten Sie, dass die 64-Bit-Version von NSSM auf diese Weise maximal 64 CPUs konfigurieren kann und dass die 32-Bit-Version ein Maxium von 32 CPUs auch beim Ausführen von 64-Bit-Fenstern konfigurieren kann.
Wenn ein Dienst an einem Dienst anhielt, wird NSSM verschiedene Methoden zum Töten der überwachten Anwendung versucht, von denen jedes bei Bedarf deaktiviert werden kann.
First NSSM wird versuchen, ein Steuer-C-Ereignis zu generieren und an die Konsole der Anwendung zu senden. Batch -Skripte oder Konsolenanwendungen können das Ereignis abfangen und sich anmutig schalten. GUI -Anwendungen haben keine Konsolen und reagieren nicht auf diese Methode.
Zweitens wird NSSM alle von der Anwendung erstellten Windows aufzählen und ihnen eine WM_CLOSE -Nachricht senden, wodurch ein anmutiger Ausgang angefordert wird.
Drittens wird NSSM alle von der Anwendung erstellten Threads aufgezählt und ihnen eine WM_quit -Nachricht sendet, wodurch ein anmutiger Ausgang angefordert wird. Nicht alle Threads von Anwendungen haben Nachrichtenwarteschlangen; Diejenigen, die nicht auf diese Methode reagieren.
Schließlich ruft NSSM TerminateProcess () auf, um zu fordern, dass das Betriebssystem die Anwendung gewaltsam beendet. TerateProcess () kann nicht gefangen oder ignoriert werden, daher wird der Antrag in den meisten Fällen getötet. Es gibt jedoch keine Garantie dafür, dass es die Möglichkeit hat, vor dem Ausgang ein Tidyup -Operationen auszuführen.
Alle oder alle oben genannten Methoden können deaktiviert sein. NSSM sucht nach dem Wert HKLM System CurrentControlSet Services <Service> Parameter appstopMethodskip Registrierungswert, der vom Typ Reg_DWord auf ein Bitfeld eingestellt sein sollte, das beschreibt, welche Methoden nicht angewendet werden sollten.
Wenn AppStopMethodskip 1 enthält, werden keine Steuer-C-Ereignisse generiert. Wenn AppStopMethodskip 2 enthält, werden WM_CLOSE -Nachrichten nicht veröffentlicht. Wenn AppStopMethodskip 4 enthält, werden Wm_quit -Nachrichten nicht veröffentlicht. Wenn AppStopMethodskip 8 enthält, wird TerateProcess () nicht aufgerufen.
Wenn Sie beispielsweise wussten, dass eine Anwendung nicht auf Kontroll-C-Ereignisse reagierte und keine Thread-Meldungswarteschlange hatte, konnten Sie AppStopMethodskip auf 5 festlegen, und NSSM würden nicht versuchen, diese Methoden zu verwenden, um die Anwendung zu stoppen.
Achten Sie auf große Vorsicht, wenn Sie 8 in den Wert von AppStopMethodskip aufnehmen. Wenn NSSM nicht terminateProcess () aufruft, ist es möglich, dass die Anwendung nicht beendet, wenn der Dienst gestoppt wird.
Standardmäßig ermöglicht NSSM den Prozessen 1500 ms, auf jede der oben beschriebenen Methoden zu reagieren, bevor sie mit dem nächsten fortfahren. Das Timeout kann pro Method konfiguriert werden, indem Reg_DWORD-Einträge in der Registrierung unter HKLM System currentControlSet Services <Service> Parameter erstellt werden.
AppStopMethodConsole AppStopMethodwindow AppStopMetHodhreads
Jeder Wert sollte auf die Anzahl der Millisekunden eingestellt werden, um zu warten. Bitte beachten Sie, dass das Timeout für jeden Vorgang im Prozessbaum der Anwendung gilt. Daher kann die tatsächliche Zeit zum Herunterfahren länger sein als die Summe aller konfigurierten Zeitüberschreitungen, wenn die Anwendung mehrere Subprozesse hervorbringt.
Um die oben genannten Stoppmethoden auf alle Prozesse im Prozessbaum der Anwendung anzuwenden und sie nur auf den ursprünglichen Anwendungsprozess anzuwenden, setzen Sie das HKLM System currentControlSet Services <Service> Parameter AppKillProcessree Registrierungswert, der vom Typ Reg_dword von 0 sein sollte.
Standardmäßig erstellt NSSM ein Konsolenfenster, sodass Anwendungen, die die Benutzereingabe lesen können, dies tun können - vorbehaltlich des Dienstes darf mit dem Desktop interagieren.
Die Erstellung der Konsole kann unterdrückt werden, indem die Integer (Reg_DWORD) HKLM System CurrentControlSet Services <Service> Parameter AppnoConsole -Registrierungswert auf 1 festgelegt wird.
NSSM kann die E/A der verwalteten Anwendung in einen beliebigen Weg umleiten, der von createFile () geöffnet werden kann. Dies ermöglicht beispielsweise das Erfassen der Protokollausgabe einer Anwendung, die sonst nur in die Konsole schreiben oder Eingaben von einem seriellen Anschluss annimmt.
NSSM wird in der Registrierung unter HKLM System CurrentControlSet Services <Service> Parametern für die Tasten, die Argumenten für createFile () entsprechen, nachsehen. Alle sind optional. Wenn für einen bestimmten Stream kein Pfad angegeben wird, wird er nicht umgeleitet. Wenn ein Pfad angegeben wird, aber einer der anderen Werte weggelassen wird, erhalten sie vernünftige Standardeinstellungen.
Appstdin: Pfad zum Empfangen von Eingaben. AppStdout: Pfad zum Empfangen von Ausgaben. Appstderr: Pfad zum Empfang von Fehlerausgaben.
Parameter für createFile () werden mit "AppstdinSharemode", "AppstdincreationDisposition" und "Appstdinflagsandattributes" -Werte (und analog für Stdout und Stderr) bereitgestellt.
Wenn Sie im Allgemeinen möchten, dass der Dienst seine Ausgabe protokolliert, setzen Sie Appstdout und Appstderr auf denselben Pfad, z. B. C: Users öffentlich service.log, und er sollte funktionieren. Denken Sie jedoch daran, dass der Pfad für den Benutzer zugänglich sein muss, der den Dienst ausführt.
Bei Verwendung der E/A -Umleitung kann NSSM vor dem Öffnen von STDOut und/oder STDERR vorhandene Ausgabedateien rotieren. Eine vorhandene Datei wird mit einem Suffix, das auf der letzten Schreibzeit der Datei basiert, in Millisekundenpräzision umbenannt. Beispielsweise kann die Datei nssm.log in NSSM-20131221T113939.457.Log gedreht werden.
NSSM wird in der Registrierung unter HKLM System CurrentControlSet Services <Service> Parametern für Reg_DWORD -Einträge nachgewiesen, welche Steuerung der Drehung steuert.
Wenn ArecrotateFiles fehlt oder auf 0 gesetzt ist, ist die Rotation deaktiviert. Jeder Wert ungleich Null ermöglicht eine Rotation.
Wenn die Anerkennung von Null nicht null ist, wird eine Datei nicht gedreht, wenn ihre letzte Schreibzeit geringer ist als die angegebene Anzahl von Sekunden in der Vergangenheit.
Wenn ArefotatateBytes ungleich Null ist, wird eine Datei nicht gedreht, wenn sie kleiner als die angegebene Anzahl von Bytes ist. 64-Bit-Dateigrößen können behandelt werden, indem ein Wert ungleich Null von AssistentsByTeshigh festgelegt wird.
Wenn die anerkannte Null-Null-Null ist, wird NSSM nach der Rotation für die angegebene Anzahl von Millisekunden innehalten.
Wenn AppStdoutCopyAndRuncate oder AppstderRCopyAndRuncate ungleich Null sind, wird die Datei STDOut (oder STDERR) gedreht, indem zuerst eine Kopie der Datei verwendet wird und die ursprüngliche Datei auf null Größe abschneidet. Dies ermöglicht es NSSM, Dateien zu drehen, die durch andere Prozesse geöffnet werden, und verhindern, dass die übliche MoveFile () erfolgreich ist. Beachten Sie, dass der Kopiervorgang einige Zeit in Anspruch nehmen kann, wenn die Datei groß ist und vorübergehend den doppelt so viel Speicherplatz wie die Originaldatei verbraucht. Beachten Sie auch, dass Anwendungen, die die Protokolldatei lesen, nicht bemerkt, dass sich die Dateigröße geändert hat. Die Verwendung dieser Option in Verbindung mit anerkanntem Aspekt kann in diesem Fall hilfreich sein.
Die Rotation ist unabhängig von den Parametern createFile (), die zum Öffnen der Dateien verwendet werden. Sie werden gedreht, unabhängig davon, ob NSSM sie sonst angehängt oder ersetzt hätte.
NSSM kann auch Dateien drehen, die den Schwellenwert für die konfigurierte Größe treffen, während der Dienst ausgeführt wird. Zusätzlich können Sie eine On-Demand-Rotation durch Ausführen des Befehls auslösen
nssm rotate <servicename>
On-Demand-Rotationen erfolgen, nachdem die nächste Datenzeile aus der verwalteten Anwendung gelesen wurde, unabhängig vom Wert von Assistenten. Beachten Sie, dass, wenn die Anwendung nicht besonders ausführlich ist, die Rotation für einige Zeit möglicherweise nicht auftritt.
Um die Online- und On-Demand-Rotation zu aktivieren, setzen Sie die ArefrotateOnline auf einen Wert ungleich Null fest.
Beachten Sie, dass die Online -Rotation erforderlich ist, dass NSSM die E/A der Anwendung abfängt und die Ausgabedateien in seinem Namen erstellt. Dies ist komplexer und fehleranfälliger, als die E/A-Streams vor dem Start der Anwendung einfach umzuleiten. Daher ist die Online -Rotation standardmäßig nicht aktiviert.
Beim Umleitungsausgang kann NSSM jede Ausgangslinie mit einem Zeitstempel von Millisekunden-Präzision vorfixieren, zum Beispiel:
2016-09-06 10:17:09.451 Pipeline main started
Setzen Sie AppTimestAmPlog auf einen Wert ungleich Null.
Das Präfix gilt sowohl für Stdout als auch für Stderr. Für das Präfixen müssen die E/A der Anwendung genauso abgeholt werden, wie dies die Online -Rotation tut. Wenn beide Protokolldrehungen und das Präfixen des Zeitstempels aktiviert sind, ist die Rotation online.
NSSM kann die Umgebung der verwalteten Anwendung ersetzen oder anhängen. Zwei Multi-bewertete String (reg_multi_sz) Registrierungswerte werden unter HKLM System CurrentControlSet Services <Service> Parameter erkannt.
Agenvironment definiert eine Liste von Umgebungsvariablen, die die Umgebung des Dienstes überschreiben. AgenvironmentExtra definiert eine Liste von Umgebungsvariablen, die in die Umgebung des Dienstes hinzugefügt werden.
Jeder Eintrag in der Liste sollte vom Formularschlüssel = Wert sein. Es ist möglich, den Wert wegzulassen, aber das = Symbol ist obligatorisch.
Umgebungsvariablen, die sowohl in Agenvironment als auch in Annenumwelt aufgeführt sind, unterliegen einer normalen Expansion. Daher ist es beispielsweise möglich, den Systempfad zu aktualisieren, indem "path = c: bin;%path%" in AnnenumweltExtra festgelegt wird. Variablen werden in der Reihenfolge erweitert, in der sie erscheinen. Wenn Sie also den Wert einer Variablen in eine andere Variable aufnehmen möchten, sollten Sie zuerst die Abhängigkeit deklarieren.
Da in Agenvironment definierte Variablen die vorhandene Umgebung überschreiben, können Sie nicht auf Variablen verweisen, die zuvor definiert wurden.
Zum Beispiel der folgende Annenumgebungsblock:
PATH=C:WindowsSystem32;C:Windows
PATH=C:bin;%PATH%
Würde zu einem Pfad von "C: bin; C: Windows System32; C: Windows" wie erwartet führen.
Während der folgende Annenumweltblock:
PATH=C:bin;%PATH%
Würde zu einem Pfad führen, der nur C: bin und wahrscheinlich dazu führen, dass die Anwendung nicht startet.
Die meisten Menschen möchten AppenvironmentExtra ausschließlich verwenden. Srvany unterstützt nur die Annenumgebung.
Ab Version 2.25 pariert NSSM vor dem Lesen anderer Registrierungswerte die Annenumgebung und Annenumwelt selbst. Infolgedessen ist es nun möglich, auf benutzerdefinierte Umgebungsvariablen in Anwendung, AppDirectory und anderen Parametern zu verweisen.
Alle Windows-Dienste können zusätzliche Umgebungsvariablen übergeben werden, indem ein Multi-bewertetes String (reg_multi_sz) Registrierungswert mit dem Namen HLKM System CurrentControlSet Services <Wartes> Umgebung erstellt werden.
Der Inhalt dieses Umgebungsblocks wird vor Beginn des Dienstes in die Systemumgebung zusammengefasst.
Beachten Sie jedoch, dass die fusionierte Umgebung vor dem Verarbeiten alphabetisch sortiert wird. Dies bedeutet, dass Sie in der Praxis beispielsweise nicht in Dir =%Programfiles%in die Umgebungsblockade festlegen können, da die an den Dienst übergebene Umgebung zum Zeitpunkt der Definition von%DIR%nicht%Programmdateds%definiert hat. Umgebungsvariablen, die in Annenumwelt definiert sind, leiden nicht unter dieser Einschränkung.
Ab Version 2.25 kann NSSM den Umgebungsblock mit ähnlichen Befehlen erhalten und festlegen:
nssm get <servicename> Environment
Es ist wiederholt, dass der Umgebungsblock für alle Windows -Dienste verfügbar ist, nicht nur für NSSM -Dienste.
Die Umgebung, die NSSM an die Anwendung übergeht, hängt davon ab, wie verschiedene Registrierungswerte konfiguriert werden. Der folgende Fluss beschreibt, wie die Umgebung geändert wird.
Standardmäßig: Der Dienst erbt die Systemumgebung.
Wenn Umgebung definiert ist: Der Inhalt der Umgebung wird in die Umwelt verschmilzt.
Wenn Parameter Annenvironment definiert ist: Der Dienst erbt die in Agenvironment angegebene Umgebung.
Wenn Parameter AntenvironmentExtra definiert ist: Der Inhalt von AnnenvironmentExtra wird an die Umgebung angehängt.
Beachten Sie, dass die Annenumgebung die Systemumgebung und den zusammengeführten Umgebungsblock überschreibt. Beachten Sie auch, dass AnnenvironmentExtra garantiert an die Startumgebung angehängt wird, wenn sie definiert ist.
NSSM kann als Antwort auf Anwendungsereignisse benutzerkonfigurierbare Befehle ausführen. Diese Befehle werden unten als "Hooks" bezeichnet.
Alle Haken sind optional. Alle Ausführungen, die ausgeführt werden, werden mit der für den Dienst konfigurierten Umgebung gestartet. NSSM stellt zusätzliche Variablen in die Umgebung ein, die Haken abfragen kann, um zu lernen, wie und warum sie gerufen wurden.
Haken werden nach Ereignis und Aktion kategorisiert. Einige Haken werden synchron ausgeführt und andere asynchron ausgeführt. Mit einem *Sternchen vorangestellte Hooks werden synchron ausgeführt. NSSM wird darauf warten, dass diese Hooks abgeschlossen werden, bevor er seine Arbeit fortsetzt. Beachten Sie jedoch, dass alle Haken einer Frist ausgesetzt sind, nach der sie getötet werden, unabhängig davon, ob sie asynchron oder nicht geführt werden oder nicht.
Ereignis: Start - Ausgelöst, wenn der Dienst zum Starten aufgefordert wird. *Aktion: PRE - vor NSSM versucht, die Anwendung zu starten. Aktion: Post - Nach erfolgreichem Start der Anwendung angerufen.
Ereignis: Stopp - Ausgelöst, wenn der Dienst zum Anhalten von Diensten aufgefordert wird. *Aktion: Pre - vor NSSM angerufen versucht, die Anwendung zu töten.
Ereignis: Beenden - Ausgelöst, wenn die Anwendung ausgeht. *Aktion: Post - Nach NSSM hat die Anwendung aufgeräumt.
Ereignis: Drehen - Ausgelöst, wenn die Online -Protokolldrehung angefordert wird. *Aktion: PRE - vor dem NSSM angerufenen Protokolle. Aktion: Post - Rufen Sie nach NSSM an, die Protokolle drehen.
Ereignis: Power Action: Änderung - Aufgerufen, wenn sich der Systemleistungsstatus geändert hat. Aktion: Lebenslauf - Aufgerufen, wenn das System aus dem Standby aufgenommen wurde.
Beachten Sie, dass es keinen Stopp/Post -Haken gibt. Dies liegt daran, dass Exit/Post aufgerufen wird, wenn die Bewerbung beendet ist, unabhängig davon, ob dies als Antwort auf eine Service -Shutdown -Anfrage geschlossen wurde. Stop/PRE wird erst vor einem anmutigen Abschaltversuch gerufen.
NSSM legt die Umgebungsvariable NSSM_HOOK_VERSION auf eine positive Zahl fest. Hooks können den Wert der Zahl überprüfen, um zu bestimmen, welche anderen Umgebungsvariablen ihnen zur Verfügung stehen.
Wenn NSSM_HOOK_VERSION 1 oder höher ist, werden diese Variablen bereitgestellt:
NSSM_EXE - Pfad zu NSSM selbst. NSSM_Configuration - Erstellen Sie Informationen für die ausführbare NSSM -Datei, z. B. 64 -Bit -Debuggen. NSSM_VERSION - Version der ausführbaren NSSM -Datei. NSSM_BUILD_DATE - Erstellen Sie das Datum von NSSM. NSSM_PID - Prozess -ID der ausführenden NSSM -ausführbaren Datei. NSSM_DEADLINE - Frist Anzahl von Millisekunden danach tötet NSSM den Haken, wenn er noch läuft. NSSM_Service_Name - Name des von NSSM gesteuerten Dienstes. NSSM_Service_DisplayName - Anzeigename des Dienstes. NSSM_Command_line - Befehlszeile zum Starten der Anwendung. NSSM_Application_PID - Prozess -ID des primären Anwendungsprozesses. Kann leer sein, wenn der Vorgang nicht ausgeführt wird. NSSM_EVENT - Ereignisklasse auslöst den Haken. NSSM_ACTION - Ereignisaktion auslöst den Haken. NSSM_TRIGGER - Dienststeuerung auslöst den Haken. Kann leer sein, wenn der Haken nicht durch eine Dienststeuerung ausgelöst wurde, z. B. Beenden/Pfosten. NSSM_LAST_CONTROL - Letzter Servicekontrolle von NSSM. NSSM_START_REQUEST_COUNT - Häufigkeit, mit der die Bewerbung zum Starten gebeten wurde. NSSM_START_COUNT - Häufigkeit, mit der die Anwendung erfolgreich gestartet wurde. NSSM_THROTTLE_COUNT - Häufigkeit, mit der die Anwendung für weniger als die Drosselklappe lief. Bei erfolgreichem Start auf Null zurücksetzen oder wenn der Dienst explizit nicht errichtet ist. NSSM_EXIT_COUNT - Anzahl der beendeten Anwendungen. NSSM_EXITCODE - Code der Anwendung beenden. Kann leer sein, wenn die Anwendung noch ausgeführt wird oder noch nicht begonnen hat. NSSM_RUNTIME - Anzahl der Millisekunden, für die die ausführbare NSSM ausgeführt wurde. NSSM_Application_Runtime - Anzahl der Millisekunden, für die die Anwendung seit dem letzten Start ausgeführt wurde. Kann leer sein, wenn die Bewerbung noch nicht gestartet wurde.
Zukünftige Versionen von NSSM bieten möglicherweise mehr Umgebungsvariablen. In diesem Fall werden NSSM_HOOK_VERSION auf eine höhere Zahl eingestellt.
Hooks werden durch das Erstellen von String -Werten (reg_expand_sz) in der Registrierung erstellt und unter HKLM System CurrentControlSet Services <Service> Parameter AppeVents <Event> platziert.
Zum Beispiel kann der Dienst so konfiguriert werden, dass das System von Standby wieder aufnimmt, indem Sie die Bereichen power resume auf:
%NSSM_EXE% restart %NSSM_SERVICE_NAME%
Verwenden Sie, um einen Haken auf der Befehlszeile festzulegen
nssm set <servicename> AppEvents <event>/<action> <command>
Beachten Sie, dass NSSM das Start der Anwendung abbricht, wenn ein Start/Pre -Hook Beschließungscode von 99 zurückgibt.
In einem Dienst wird normalerweise Hooks in der folgenden Reihenfolge ausgeführt:
Start/Pre Start/Post Stop/Pre Exit/Post
Wenn die Anwendung abstürzt und von NSSM neu gestartet wird, kann die Bestellung lautet:
Start/Pre Start/Post Exit/Post Start/Pre Start/Post Stop/Pre Exit/Post
Wenn NSSM STDOut oder STDERR umleitet, kann es so konfiguriert werden, dass die Ausgabe aller von ihm ausgeführten Hooks umleitet. Stellen Sie die AppreTirecthooks auf 1 ein, um diese Funktionalität zu aktivieren. Ein Haken kann natürlich unabhängig von NSSM seine eigene I/O -I/A umleiten.
NSSM kann die Einstellungen vorhandener Dienste mit derselben GUI bearbeiten, die zur Installation verwendet wird. Laufen
nssm edit <servicename>
die GUI aufzunehmen.
NSSM bietet nur begrenzte Bearbeitungsfunktionen für andere Dienste als diejenigen, die NSSM selbst betreiben. Wenn NSSM aufgefordert wird, einen Dienst zu bearbeiten, der nicht über die oben beschriebenen App* -Enregistrierungseinstellungen verfügt, ermöglicht die GUI nur die Bearbeitung von Systemeinstellungen wie den Namensschild und die Beschreibung des Dienstes.
NSSM kann einzelne Dienstparameter aus der Befehlszeile abrufen oder festlegen. Im Allgemeinen ist die Syntax wie folgt, wenn auch nach unten für Ausnahmen.
nssm get <servicename> <parameter>
nssm set <servicename> <parameter> <value>
Parameter können auch auf ihre Standardwerte zurückgesetzt werden.
nssm reset <servicename> <parameter>
Die von NSSM erkannten Parameternamen entsprechen den oben beschriebenen Registrierungseintragsnamen z. B. AppDirectory.
NSSM bietet nur begrenzte Bearbeitungsfunktionen für andere Dienste als diejenigen, die NSSM selbst betreiben. Die anerkannten Parameter sind wie folgt:
Beschreibung: Service Beschreibung. DisplayName: Service -Anzeigename. Umwelt: Service fusioniert Umgebung. ImagePath: Pfad zum ausführbaren Dienst. Objektname: Benutzerkonto, das den Dienst ausführt. Name: Serviceschlüsselname. Start: Service Startup -Typ. Typ: Service Typ.
Diese entsprechen den Registrierungswerten unter dem Schlüssel HKLM System CurrentControlSet Services <Service> des Dienstes.
Beachten Sie, dass NSSM alle Argumente, die an der Befehlszeile übergeben wurden, mit Leerzeichen verkettet werden, um den für die festgelegten Wert zu bilden. Somit hätten die folgenden zwei Aufrufe den gleichen Effekt.
nssm set <servicename> Description "NSSM managed service"
nssm set <servicename> Description NSSM managed service
Die Parameter Agenvironment, AngenvironmentExtra und Umgebung erkennen ein zusätzliches Argument bei der Abfrage der Umgebung. Die folgende Syntax druckt alle zusätzlichen Umgebungsvariablen, die für einen Dienst konfiguriert sind
nssm get <servicename> AppEnvironmentExtra
Während die folgende Syntax nur den Wert der ClassPath -Variablen druckt, wenn sie im Umgebungsblock konfiguriert ist, oder in der leeren Zeichenfolge, wenn sie nicht konfiguriert ist.
nssm get <servicename> AppEnvironmentExtra CLASSPATH
Beim Einstellen eines Umgebungsblocks sollte jede Variable in separaten Befehlszeilenargumenten als Schlüssel = Wertpaar angegeben werden. Zum Beispiel:
nssm set <servicename> AppEnvironment CLASSPATH=C:Classes TEMP=C:Temp
Alternativ kann der Schlüssel mit A + oder - Symbol vorangestellt werden, um ein Paar aus dem Block hinzuzufügen oder zu entfernen.
Die folgenden zwei Zeilen setzen Klassenpfad und Temperatur:
nssm set <servicename> AppEnvironment CLASSPATH=C:Classes
nssm set <servicename> AppEnvironment +TEMP=C:Temp
Wenn der Schlüssel bereits vorhanden ist, überschreiben Sie den Wert, während die Reihenfolge der Schlüssel erhalten wird:
nssm set <servicename> AppEnvironment +CLASSPATH=C:NewClasses
Die folgende Syntax entfernt eine einzelne Variable aus dem Block, während andere Variablen an Ort und Stelle bleiben.
nssm set <servicename> AppEnvironment -TEMP
Angeben -key = Wert entfernen die Variable nur, wenn der vorhandene Wert übereinstimmt.
Die folgende Syntax würde Temp = C: Temp nicht entfernen
nssm set <servicename> AppEnvironment -TEMP=C:WorkTemporary
Die + und - Symbole sind gültige Zeichen in Umgebungsvariablen. Die Syntax: KEY = Value entspricht Key = Wert und kann verwendet werden, um Variablen festzulegen, die mit +/-- oder den Block in einem Skript explizit zurücksetzen:
nssm set <servicename> AppEnvironment :CLASSPATH=C:Classes
nssm set <servicename> AppEnvironment +TEMP=C:Temp
Für den Parameter von Appexit ist ein zusätzliches Argument erforderlich, in dem der Ausgangscode angegeben wird, um zu erhalten oder festzulegen. Die Standardaktion kann mit der String -Standardeinstellung angegeben werden.
Um beispielsweise die Standard -Exit -Aktion für einen Dienst zu erhalten, sollten Sie ausgeführt werden
nssm get <servicename> AppExit Default
Um die Beendenaktion zu erhalten, wenn die Anwendung mit dem Exit -Code 2 beendet wird, führen Sie aus
nssm get <servicename> AppExit 2
Beachten Sie, dass NSSM die Standard -Exit -Aktion druckt, wenn keine explizite Aktion für einen angegebenen Exit -Code konfiguriert ist.
So setzen
nssm set <servicename> AppExit 2 Exit
Der Apppriority -Parameter wird verwendet, um die Prioritätsklasse der verwalteten Anwendung festzulegen. Gültige Prioritäten sind wie folgt:
Realtime_priority_class High_Priority_Class ober_Normal_Priority_Class NORMAL_PRIORITY_CLASS unterunter_Normal_Priority_Class Idle_Priority_Class
Die Abhängigkeits- und Abhängigkeitsparameter werden verwendet, um die Abhängigkeiten für den Dienst abzufragen oder festzulegen. Beim Einstellen von Abhängigkeiten sollten in separaten Befehlszeilenargumenten jede Dienst- oder Dienstgruppe (vorangegangen mit dem + -Symbol) angegeben werden. Zum Beispiel:
nssm set <servicename> DependOnService RpcSs LanmanWorkstation
Alternativ kann der Abhängigkeitsname mit einem + oder - Symbol vorangestellt werden, um eine Abhängigkeit hinzuzufügen oder zu entfernen.
Die folgenden zwei Zeilen setzen Abhängigkeiten von RPCSS und LanmanworkStation:
nssm set <servicename> DependOnService RpcSs
nssm set <servicename> DependOnService +LanmanWorkstation
Die Follwing -Syntax beseitigt die Abhängigkeit von RPCSs:
nssm set <servicename> DependOnService -RpcSs
Servicegruppen sollten streng genommen mit dem + -Symbol vorangestellt werden. Um eine einzelne Abhängigkeit von einer Gruppe anzugeben, kann das + -Symbol mit dem Symbol vorangestellt werden.
Die folgenden Zeilen sind äquivalent, und jeder setzt eine Abhängigkeit nur für Netbiosgroup:
nssm set <servicename> DependOnGroup NetBIOSGroup
nssm set <servicename> DependOnGroup :NetBIOSGroup
nssm set <servicename> DependOnGroup :+NetBIOSGroup
Während diese Zeilen zu bestehenden Abhängigkeiten hinzufügen:
nssm set <servicename> DependOnGroup +NetBIOSGroup
nssm set <servicename> DependOnGroup ++NetBIOSGroup
Der Name Parameter kann nur abgefragt und nicht festgelegt werden. Es gibt den Registrierungsschlüsselnamen des Dienstes zurück. Dies kann nützlich sein, um zu wissen, ob Sie die Tatsache nutzen, dass Sie den Anzeigenamen des Dienstes überall dort ersetzen können, wo die Syntax fordert.
Der Objektname -Parameter erfordert nur ein zusätzliches Argument, wenn ein Benutzername festgelegt wird. Das zusätzliche Argument ist das Passwort des Benutzers.
Um den Benutzernamen abzurufen, laufen Sie
nssm get <servicename> ObjectName
Um den Benutzernamen und das Passwort festzulegen, laufen Sie aus
nssm set <servicename> ObjectName <username> <password>
Beachten Sie, dass die Argumentationsverkampferung noch gelten. Der folgende Aufruf ist gültig und hat den erwarteten Effekt.
nssm set <servicename> ObjectName <username> correct horse battery staple
Die folgenden bekannten Benutzernamen benötigen kein Passwort. Der Kennwortparameter kann bei der Verwendung weggelassen werden:
"LocalSystem" alias "System" alka "nt Authority System" "Lokalservice" alias "Lokaler Dienst" alka "NT Authority Lokal Service" "Netzwerkservice" alka "Netzwerkdienst" alka "NT Authority Network Service" Virtual Service Account "NT Service <Servicemame>"
Der Startparameter wird zum Abfragen oder Festlegen des Starttyps des Dienstes verwendet. Gültige Service -Start -up -Typen sind wie folgt:
Service_auto_start: Automatisches Start beim Boot. Service_delayed_start: Verzögertes Start beim Boot. Service_demand_start: Manuelles Service -Start. Service_disabled: Der Dienst ist deaktiviert.
Beachten Sie, dass Service_Delayed_start vor Vista nicht auf Versionen von Windows unterstützt wird. NSSM setzt den Dienst auf automatisches Start, wenn der verzögerte Start nicht verfügbar ist.
Der Typ -Parameter wird verwendet, um den Service -Typ abzufragen oder festzustellen. NSSM erkennt alle aktuell dokumentierten Service -Typen an, ermöglicht jedoch nur die Einstellung eines von zwei Typen:
Service_win32_own_process: ein eigenständiger Service. Dies ist der Standard. Service_interactive_process: Ein Dienst, der mit dem Desktop interagieren kann.
Beachten Sie, dass ein Dienst möglicherweise nur als interaktiv konfiguriert sein kann, wenn er unter dem Konto des LocalSystems ausgeführt wird. Die sichere Möglichkeit, einen interaktiven Dienst zu konfigurieren, liegt in zwei Phasen wie folgt.
nssm reset <servicename> ObjectName
nssm set <servicename> Type SERVICE_INTERACTIVE_PROCESS
NSSM bietet rudimentäre Service -Steuerungsfunktionen.
nssm start <servicename>
nssm restart <servicename>
nssm stop <servicename>
nssm status <servicename>
nssm statuscode <servicename>
Die Ausgabe von "NSSM -Status" und "NSSM StatusCode" ist eine Zeichenfolge, die den Dienstzustand darstellt, z. B. service_running.
Der Ausgangscode "NSSM -Status" beträgt 0, wenn der Status erfolgreich abgerufen wurde. Wenn der Exit -Code nicht Null ist, gab es einen Fehler.
Der Ausgangscode von "NSSM StatusCode" ist der numerische Wert des Dienstzustands, z. B. 4 für service_running. Null ist kein gültiger Service -Statuscode. Wenn der Exit -Code Null ist, gab es einen Fehler.
NSSM kann auch Dienste entfernen. Laufen
nssm remove <servicename>
einen Dienst entfernen. Sie werden zur Bestätigung aufgefordert, bevor der Dienst entfernt wird. Versuchen Sie nicht, essentielle Systemdienste zu entfernen ...
Um einen Dienst ohne Bestätigung aus der GUI zu entfernen, laufen Sie
nssm remove <servicename> confirm
Versuchen Sie nicht, essentielle Systemdienste zu entfernen ...
NSSM -Protokollierung im Windows -Ereignisprotokoll. Es registriert sich selbst als Ereignisprotokollquelle und verwendet eindeutige Ereignis -IDs für jede Art von Nachrichten, die es Protokolle abweist. Neue Versionen können Ereignisstypen hinzufügen, aber vorhandene Ereignis -IDs werden niemals geändert.
Aufgrund der Art und Weise, wie sich NSSM selbst registriert, sollten Sie sich bewusst sein, dass Sie möglicherweise nicht in der Lage sind, das NSSM -Binary zu ersetzen, wenn Sie den Ereignisbieter geöffnet haben und dass das Ausführen mehrerer Instanzen von NSSM von verschiedenen Orten möglicherweise verwirrend ist, wenn sie nicht alle gleich sind.
Im folgenden Befehl werden die Namen aller von NSSM verwalteten Dienste gedruckt:
nssm list
Um alle Dienste auf dem System zu sehen, nicht nur NSSMs, verwenden Sie die Liste alle:
nssm list all
Der folgende Befehl druckt die Prozess -ID und den ausführbaren Weg der Prozesse, die von einem bestimmten Dienst gestartet wurden:
nssm processes <servicename>
Beachten Sie, dass wenn 32-Bit-NSSM auf einem 64-Bit-System ausgeführt wird, das eine ältere Version von Windows als Vista ausführt, die Pfade von 64-Bit-Prozessen nicht abfragen kann.
NSSM kann Befehle abwerfen, die die Konfiguration eines Dienstes nachbilden würden. Die Ausgabe kann in ein Batch -Skript eingefügt werden, um den Dienst zu sichern oder auf einen anderen Computer zu übertragen.
nssm dump <servicename>
Da die Servicekonfiguration Zeichen enthalten kann, die aus der Eingabeaufforderung zitiert oder entkommen müssen, bemüht sich NSSM, die Ausgabe zu erzeugen, die beim Ausführen als Skript korrekt funktioniert, indem Zitate und Care -Flucht gegebenenfalls entkommen.
Um das Kopieren eines Dienstes zu erleichtern, akzeptiert der Dump -Befehl ein zweites Argument, das den Namen des Dienstes angibt, der in der Ausgabe verwendet werden soll.
nssm dump <servicename> <newname>
Zeilen im Dump verweisen auf den Dienst, während die Konfiguration von angezeigt wird.
So installieren Sie einen unwirklichen Turnierserver:
nssm install UT2004 c:gamesut2004systemucc.exe server
So führen Sie den Server als "Spiele" -Nutzer aus:
nssm set UT2004 ObjectName games password
So konfigurieren Sie den Server so, dass sie sich bei einer Datei anmelden:
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.
