NSSM
v2.25
NSSM est un programme d'assistance de service similaire à Srvany et CyGrunSRV. Il peut démarrer n'importe quelle application (telle que Console) en tant que service NT et redémarrera le service en cas d'échec pour une raison quelconque.
NSSM possède également un installateur de services graphiques et un déménageur.
Ceci est une fourche de NSSM
Fichiers binaires que vous pouvez trouver dans les versions ici
Code d'origine: https://git.nssm.cc/nssm/nssm par Iain Patterson
Documentation: utilisation, commandes
Dans les notes d'utilisation ci-dessous, les arguments du programme peuvent être écrits sous des supports d'angle et / ou des crochets. signifie que vous devez insérer la chaîne appropriée et [] signifie que la chaîne est facultative. Voir les exemples ci-dessous ...
Notez que partout, vous pouvez remplacer le nom d'affichage du service.
Pour installer un service, exécutez
nssm install <servicename>
Vous serez invité à saisir le chemin complet de l'application que vous souhaitez exécuter et toutes les options de ligne de commande pour passer à cette application.
Utilisez le System Service Manager (Services.MSC) pour contrôler les propriétés de service avancées telles que la méthode de démarrage et l'interaction de bureau. NSSM peut prendre en charge ces options ultérieurement ...
Pour installer un service, exécutez
nssm install <servicename> <application> [<options>]
NSSM tentera alors d'installer un service qui exécute l'application nommée avec les options données (si vous en avez spécifié).
N'oubliez pas de joindre des chemins dans des "citations" s'ils contiennent des espaces!
Si vous souhaitez inclure des devis dans les options, vous devrez "" "cite" "" les citations.
NSSM lancera l'application répertoriée dans le registre lorsque vous lui envoyez un signal de démarrage et la terminera lorsque vous envoyez un signal d'arrêt. Jusqu'à présent, un peu comme Srvany. Mais NSSM est le gestionnaire de services non-sujets et peut prendre des mesures si / quand l'application décède.
Sans configuration de votre part, NSSM essaiera de se redémarrer s'il remarque que l'application est morte, mais vous ne l'avez pas envoyé de signal d'arrêt. NSSM continuera d'essayer, s'arrêtant entre chaque tentative, jusqu'à ce que le service soit démarré avec succès ou que vous lui envoyez un signal d'arrêt.
Le NSSM suscitera un temps de plus en plus long entre les tentatives de redémarrage ultérieures si le service ne commence pas en temps opportun, jusqu'à un maximum de quatre minutes. C'est ainsi qu'il ne consomme pas une quantité excessive de temps CPU essayant de démarrer une application ratée encore et encore. Si vous identifiez la cause de l'échec et que vous ne souhaitez pas attendre, vous pouvez utiliser la console de service Windows (où le service sera affiché à l'état pause) pour envoyer un signal de continu à NSSM et il réessayera en quelques secondes.
Par défaut, NSSM définit "une manière en temps opportun" pour être à moins de 1500 millisecondes. Vous pouvez modifier le seuil pour le service en définissant le nombre de millisecondes en tant que valeur Reg_dword dans le registre de HKLM System CurrentControlset Services <Serfe> Paramètres AppThrottle.
Alternativement, le NSSM peut s'arrêter pendant un temps configurable avant d'essayer de redémarrer l'application même s'il a été exécuté avec succès pendant la durée spécifiée par Appthrottle. NSSM consultera la valeur Reg_DWord sur HKLM System CurrentControlset Services <Serfe> Paramètres AppRestartDelay pour le nombre de millisecondes à attendre avant d'essayer un redémarrage. Si ApprestartDelay est défini et que l'application est déterminée comme étant soumise à la limitation, NSSM suscitera le service pour le plus long du délai de redémarrage configuré et de la période de gaz calculée.
Si ApprestartDelay est manquant ou invalide, seule la limitation sera appliquée.
NSSM examinera le registre sous HKLM System CurrentControlset Services <fread> Paramètres AppExit pour les valeurs de chaîne (reg_expand_sz) correspondant au code de sortie de l'application. Si l'application est sortie avec le code 1, par exemple, NSSM recherchera une valeur de chaîne sous Appexit appelée "1" ou, si elle ne le trouve pas, il se repliera à la valeur Appexit (par défaut). Vous pouvez trouver le code de sortie de l'application en consultant le journal des événements système. NSSM enregistrera le code de sortie à la sortie de l'application.
Sur la base des données trouvées dans le registre, le NSSM prendra l'une des trois actions:
Si les données de valeur sont "redémarrer" NSSM essaiera de redémarrer l'application comme décrit ci-dessus. C'est son comportement par défaut.
Si les données de valeur sont «ignorer» NSSM n'essaieront pas de redémarrer l'application mais continuera à s'exécuter elle-même. Cela émule le comportement (généralement indésirable) de Srvany. La console des services Windows afficherait le service comme étant en cours d'exécution, même si l'application est sortie.
Si les données de valeur sont "quitter" NSSM quitteront gracieusement. La console des services Windows afficherait le service comme arrêté. Si vous souhaitez fournir un contrôle plus fin sur la récupération de service, vous devez utiliser ce code et modifier manuellement l'action de défaillance. Veuillez noter que les versions Windows avant Vista ne considéreront pas une telle sortie comme un échec. Sur les versions plus anciennes de Windows, vous devez utiliser le "suicide" à la place.
Si les données de valeur sont "Suicide" NSSM simulent un crash et quittent sans informer le gestionnaire de services. Cette option ne doit être utilisée que pour les systèmes pré-viviques où vous souhaitez appliquer une action de récupération de service. Notez que si l'application surveillée sort avec le code 0, NSSM ne s'honorera qu'une demande de suicide si vous configurez explicitement une clé de registre pour le code de sortie 0. Si seule l'action par défaut est définie sur le suicide NSSM quittera plutôt gracieusement.
NSSM peut définir la classe prioritaire de l'application gérée. NSSM examinera le registre sous HKLM System CurrentControlset Services <ferge> Paramètres pour le reg_dword Entry Appriority. Les valeurs valides correspondent aux arguments à setPriorityClass (). Si Appriority () est manquant ou invalide, l'application sera lancée avec une priorité normale.
NSSM peut définir l'affinité CPU de l'application gérée. NSSM examinera le registre sous HKLM System CurrentControlset Services <fread> Paramètres pour l'appaffinité de l'entrée Reg_SZ. Il doit spécifier une liste de virgule répertoriée des ID de processeur indexé zéro. Une gamme de processeurs peut éventuellement être spécifiée avec un tableau de bord. Aucun autre caractères n'est autorisé dans la chaîne.
Par exemple, pour spécifier le premier; deuxième; Troisième et cinquième processeurs, une appaffinité appropriée serait de 0-2,4.
Si AppAffinity est manquant ou non valide, NSSM n'essaiera pas de restreindre l'application à des CPU spécifiques.
Notez que la version 64 bits de NSSM peut configurer un maximum de 64 CPU de cette manière et que la version 32 bits peut configurer un maxium de 32 CPU même lorsqu'il s'exécute sous Windows 64 bits.
Lors de l'arrêt d'un service, NSSM tentera plusieurs méthodes différentes pour tuer l'application surveillée, chacune peut être désactivée si nécessaire.
First NSSM tentera de générer un événement Control-C et l'envoie à la console de l'application. Les scripts par lots ou les applications de console peuvent intercepter l'événement et s'arrêter gracieusement. Les applications GUI n'ont pas de consoles et ne répondront pas à cette méthode.
Deuxièmement, NSSM énumera toutes les fenêtres créées par l'application et leur enverra un message WM_CLOSE, demandant une sortie gracieuse.
Troisièmement, NSSM énumera tous les threads créés par l'application et leur enverra un message WM_QUIT, demandant une sortie gracieuse. Tous les threads des applications n'ont pas les files d'attente de messages; Ceux qui ne répondront pas à cette méthode.
Enfin, NSSM appellera TermineProcess () pour demander que le système d'exploitation mette fin à la demande de force. TerminalProcess () ne peut pas être piégé ou ignoré, donc dans la plupart des cas, la demande sera tuée. Cependant, il n'y a aucune garantie qu'il aura la possibilité d'effectuer des opérations Tidyup avant sa sortie.
Toute ou toutes les méthodes ci-dessus peuvent être désactivées. NSSM recherchera le HKLM System CurrentControlset Services <Serfe> Paramètres AppstopMethodsKip Registry Valeur qui doit être de type Reg_dword défini sur un champ de bit décrivant quelles méthodes ne doivent pas être appliquées.
Si AppStopMethoDSkip comprend 1, les événements Control-C ne seront pas générés. Si AppStopMethoDSkip comprend 2, les messages WM_CLOSE ne seront pas publiés. Si AppStopMethoDSkip comprend 4, les messages WM_QUIT ne seront pas publiés. Si AppStopMethoDSkip comprend 8, TermineProcess () ne sera pas appelé.
Si, par exemple, vous saviez qu'une application ne répondait pas aux événements Control-C et n'avait pas de file d'attente de messages de thread, vous pouvez définir AppStopMethodskip vers 5 et NSSM n'essaierait pas d'utiliser ces méthodes pour arrêter l'application.
Faites très attention lorsque vous y incluez 8 dans la valeur d'AppStopMethodskip. Si NSSM n'appelle pas TermineProcess (), il est possible que l'application ne sorte pas lorsque le service s'arrête.
Par défaut, NSSM permettra aux processus 1500 ms de répondre à chacune des méthodes décrites ci-dessus avant de passer à la suivante. Le délai d'expiration peut être configuré sur une base par méthode en créant des entrées Reg_dword dans le registre sous Hklm System CurrentControlset Services <Serfe> Paramètres.
AppStopMethodconsole AppstopMethodWindow AppstopMethodThreads
Chaque valeur doit être définie sur le nombre de millisecondes à attendre. Veuillez noter que le délai d'expiration s'applique à chaque processus de l'arborescence de processus de l'application, de sorte que le temps réel de l'arrêt peut être plus long que la somme de tous les délais d'expiration configurés si l'application engendre plusieurs sous-processus.
Pour sauter l'application des méthodes d'arrêt ci-dessus à tous les processus de l'arborescence de processus de l'application, en les appliquant uniquement au processus d'application d'origine, définissez la valeur de registre HKLM System CurrentControlset Services <Service> Paramètres AppkillProcessTree, qui devrait être de type reg_dword, à 0.
Par défaut, NSSM créera une fenêtre de console afin que les applications capables de lire l'entrée utilisateur puissent le faire - sous réserve du service autorisé à interagir avec le bureau.
La création de la console peut être supprimée en définissant l'intégralité (reg_dword) hklm system currentControlset Services <Serger> Paramètres Appnoconsole Registre Valeur à 1.
NSSM peut rediriger les E / S de l'application gérée sur n'importe quel chemin capable d'être ouvert par CreateFile (). Cela permet, par exemple, la capture de la sortie du journal d'une application qui n'écrirait autrement à la console ou n'acceptant les entrées d'un port série.
NSSM examinera le registre sous HKLM System CurrentControlset Services <Service> Paramètres pour les touches correspondant aux arguments à CreateFile (). Tous sont facultatifs. Si aucun chemin n'est donné pour un flux particulier, il ne sera pas redirigé. Si un chemin est donné, mais l'une des autres valeurs est omise, elle recevra des défauts sensibles.
Appstdin: chemin pour recevoir l'entrée. Appstdout: chemin pour recevoir la sortie. Appstderr: chemin pour recevoir une sortie d'erreur.
Les paramètres pour CreateFile () fournissent des valeurs "AppStDinshareMode", "AppStDinCreationDisposition" et "AppStDinFlagsandattributes" (et de manière analogue pour STDOUT et STDERR).
En général, si vous souhaitez que le service enregistre sa sortie, définissez AppStdout et AppStderr sur le même chemin, par exemple C: Users public Service.log, et cela devrait fonctionner. N'oubliez pas, cependant, que le chemin doit être accessible à l'utilisateur exécutant le service.
Lorsque vous utilisez une redirection d'E / S, NSSM peut faire tourner les fichiers de sortie existants avant d'ouvrir STDOUT et / ou STDERR. Un fichier existant sera renommé avec un suffixe basé sur la dernière heure d'écriture du fichier, à la milliseconde précision. Par exemple, le fichier NSSM.log peut être tourné vers NSSM-20131221T113939.457.log.
NSSM sera consacré au registre sous HKLM System CurrentControlset Services <Serger> Paramètres pour les entrées Reg_dword qui contrôlent comment la rotation se produit.
Si ApproTateFiles est manquant ou réglé sur 0, la rotation est désactivée. Toute valeur non nulle permet une rotation.
Si desConcondes appropriées sont non nuls, un fichier ne sera pas tourné si son dernier temps d'écriture est inférieur au nombre donné de secondes dans le passé.
Si ApproTateBytes est non nul, un fichier ne sera pas tourné s'il est plus petit que le nombre d'octets donné. Les tailles de fichiers 64 bits peuvent être gérées en définissant une valeur non nulle de ApproTateBytesHigh.
Si ApproateDELAY n'est pas nul, le NSSM s'arrêtera pour le nombre donné de millisecondes après rotation.
Si appstdoutCopyAndTruncate ou appstderrcopyAndTruncate sont non nuls, le fichier stdout (ou stderr respectivement) sera tourné en prenant d'abord une copie du fichier, puis tronquant le fichier d'origine à la taille zéro. Cela permet à NSSM de faire pivoter des fichiers qui sont ouverts par d'autres processus, empêchant la réussite de MoveFile () habituelle. Notez que le processus de copie peut prendre un certain temps si le fichier est grand et consommera temporairement deux fois plus d'espace disque que le fichier d'origine. Notez également que les applications lisant le fichier journal peuvent ne pas remarquer que la taille du fichier a changé. L'utilisation de cette option en conjonction avec ApproteDelay peut aider dans ce cas.
La rotation est indépendante des paramètres createFile () utilisés pour ouvrir les fichiers. Ils seront tournés, que le NSSM les aurait autrement annexés ou les remplacerait.
NSSM peut également faire pivoter des fichiers qui frappent le seuil de taille configuré pendant l'exécution du service. De plus, vous pouvez déclencher une rotation à la demande en exécutant la commande
nssm rotate <servicename>
Les rotations à la demande se produiront après la lecture de la prochaine ligne de données à partir de l'application gérée, quelle que soit la valeur des abordants. Sachez que si l'application n'est pas particulièrement verbeuse, la rotation peut ne pas se produire pendant un certain temps.
Pour activer la rotation en ligne et à la demande, définissez ApproTateOnline sur une valeur non nulle.
Notez que la rotation en ligne nécessite NSSM pour intercepter les E / S de l'application et créer les fichiers de sortie en son nom. Ceci est plus complexe et plus sujet aux erreurs que de simplement rediriger les flux d'E / S avant de lancer l'application. Par conséquent, la rotation en ligne n'est pas activée par défaut.
Lors de la redirection de la sortie, NSSM peut préfixer chaque ligne de sortie avec un horodatage milliseconde de précision, par exemple:
2016-09-06 10:17:09.451 Pipeline main started
Pour activer la préfixation d'horodatage, définissez Apptimestamplog sur une valeur non nulle.
Le préfixe s'applique à la fois à STDOUT et à STDERR. Le préfixe nécessite d'intercepter les E / S de l'application de la même manière que la rotation en ligne. Si la rotation des journaux et la préfixation de l'horodatage sont toutes deux activées, la rotation sera en ligne.
NSSM peut remplacer ou ajouter à l'environnement de l'application gérée. Les valeurs de registre de deux chaînes multi-valeurs (reg_multi_sz) sont reconnues sous Hklm System CurrentControlset Services <Serfe> Paramètres.
L'appenvironnement définit une liste de variables d'environnement qui remplaceront l'environnement du service. AppenvironmentExtra définit une liste de variables d'environnement qui seront ajoutées à l'environnement du service.
Chaque entrée de la liste doit être de la valeur Formulaire = valeur. Il est possible d'omettre la valeur mais le symbole = est obligatoire.
Les variables d'environnement répertoriées dans l'appenvironment et AppenIironmentExtra sont soumises à une expansion normale, il est donc possible, par exemple, de mettre à jour le chemin du système en définissant "path = c: bin;% path%" dans AppenIironmentExtra. Les variables sont élargies dans l'ordre dans lequel ils apparaissent, donc si vous souhaitez inclure la valeur d'une variable dans une autre variable, vous devez d'abord déclarer la dépendance.
Étant donné que les variables définies dans l'appenvironment l'emportent sur l'environnement existant, il n'est pas possible de se référer aux variables qui ont été précédemment définies.
Par exemple, le bloc d'appenvironment suivant:
PATH=C:WindowsSystem32;C:Windows
PATH=C:bin;%PATH%
Entraînerait un chemin de "C: bin; C: Windows System32; C: Windows" comme prévu.
Tandis que le bloc d'appenvironment suivant:
PATH=C:bin;%PATH%
Entraînerait un chemin ne contenant que C: bin et entraînerait probablement le démarrage de l'application.
La plupart des gens voudront utiliser exclusivement AppenironmentExtra. Srvany ne prend en charge que l'Appenvironment.
À partir de la version 2.25, NSSM parses Appenvironment et AppenvironmentExtra lui-même, avant de lire toute autre valeur de registre. Par conséquent, il est désormais possible de se référer aux variables d'environnement personnalisées dans l'application, l'approdure et les autres paramètres.
Tous les services Windows peuvent être transmis de variables d'environnement supplémentaires en créant une valeur de registre de chaîne à valeur multiple (reg_multi_sz) nommée HLKM System CurrentControlset Services <ferge> Environment.
Le contenu de ce bloc d'environnement sera fusionné dans l'environnement système avant le début du service.
Notez cependant que l'environnement fusionné sera trié par ordre alphabétique avant d'être traité. Cela signifie que dans la pratique, vous ne pouvez pas définir, par exemple, Dir =% ProgramFiles% dans le bloc d'environnement car l'environnement transmis au service n'aura pas défini% ProgramFiles% au moment de définir% Dir%. Les variables environnementales définies dans AppenIronmentExtra ne souffrent pas de cette limitation.
À partir de la version 2.25, NSSM peut obtenir et définir le bloc d'environnement à l'aide de commandes similaires à:
nssm get <servicename> Environment
Il convient de réitérer que le bloc d'environnement est disponible pour tous les services Windows, pas seulement les services NSSM.
L'environnement NSSM passe à l'application dépend de la configuration de diverses valeurs de registre. Le flux suivant décrit comment l'environnement est modifié.
Par défaut: le service hérite de l'environnement système.
Si l'environnement est défini: le contenu de l'environnement est fusionné dans l'environnement.
Si Paramètres Appenvironment est défini: le service hérite de l'environnement spécifié dans Appenvironment.
Si Paramètres AppenIironmentExtra est défini: le contenu d'AppenvironmentExtra est annexé à l'environnement.
Notez que l'appenvironment remplace l'environnement système et le bloc d'environnement fusionné. Notez également qu'AppenvironmentExtra est garanti d'être annexé dans l'environnement de démarrage s'il est défini.
NSSM peut exécuter des commandes configurables par l'utilisateur en réponse aux événements d'application. Ces commandes sont appelées "crochets" ci-dessous.
Tous les crochets sont facultatifs. Tous les crochets exécutés seront lancés avec l'environnement configuré pour le service. NSSM placera des variables supplémentaires dans l'environnement que les crochets peuvent interroger pour apprendre comment et pourquoi ils ont été appelés.
Les crochets sont classés par événement et action. Certains crochets sont exécutés de manière synchrone et certains sont exécutés de manière asynchrone. Les crochets préfixés avec un * astérisque sont exécutés de manière synchrone. NSSM attendra que ces crochets se terminent avant de poursuivre ses travaux. Notez, cependant, que tous les crochets sont soumis à une date limite, après quoi ils seront tués, qu'ils soient gérés de manière asynchrone ou non.
Événement: Démarrage - Déclenché lorsque le service est invité à démarrer. * Action: pré - appelé avant NSSM tente de lancer l'application. Action: Post - appelé après le début de l'application.
Événement: arrêt - déclenché lorsque le service est invité à s'arrêter. * Action: pré - appelé avant le NSSM tente de tuer la demande.
Événement: Exit - déclenché lorsque l'application sort. * Action: Post - appelé après que NSSM ait nettoyé l'application.
Événement: Rotation - déclenché lorsque la rotation du journal en ligne est demandée. * Action: pré - appelé avant NSSM tourne les journaux. Action: Post - appelé après NSSM tourne les journaux.
Événement: Action de puissance: Modifier - appelé lorsque l'état de puissance du système a changé. Action: CV - Appelé lorsque le système a repris de la veille.
Notez qu'il n'y a pas de crochet d'arrêt / poteau. En effet, la sortie / post est appelée lorsque l'application sort, qu'elle le fasse en réponse à une demande d'arrêt de service. STOP / PRE n'est appelé qu'avant une tentative de fermeture gracieuse.
NSSM définit la variable d'environnement NSSM_HOOK_VERION à un nombre positif. Les crochets peuvent vérifier la valeur du nombre pour déterminer quelles autres variables d'environnement sont à leur disposition.
Si nssm_hook_version est 1 ou plus, ces variables sont fournies:
NSSM_EXE - Chemin vers NSSM lui-même. NSSM_Configuration - Créer des informations pour l'exécutable NSSM, par exemple le débogage 64 bits. NSSM_Version - Version de l'exécutable NSSM. NSSM_BUILD_DATE - Date de construction de NSSM. NSSM_PID - ID de processus de l'exécutable NSSM exécuté. NSSM_DEADLINE - Numéro de la date limite de millisecondes, après quoi NSSM tuera le crochet s'il est toujours en cours d'exécution. NSSM_SERVICE_NAME - Nom du service contrôlé par NSSM. NSSM_SERVICE_DISPlayName - Afficher le nom du service. NSSM_COMMAND_LINE - Ligne de commande utilisée pour lancer l'application. NSSM_APPLICATION_PID - ID de processus du processus d'application principal. Peut être vide si le processus n'est pas en cours d'exécution. NSSM_EVENT - Classe d'événements déclenchant le crochet. NSSM_ACTION - Action de l'événement déclenchant le crochet. NSSM_Trigger - Contrôle de service déclenchant le crochet. Peut être vide si le crochet n'a pas été déclenché par un contrôle de service, par exemple la sortie / post. NSSM_LAST_Control - Dernier contrôle de service géré par NSSM. NSSM_START_REQUEST_COUNT - Nombre de fois que l'application a été priée de démarrer. NSSM_START_COUNT - Nombre de fois que l'application a commencé avec succès. NSSM_THROTTLE_COUNT - Nombre de fois où l'application était inférieure à la période d'accélérateur. Réinitialisez à zéro sur le démarrage réussi ou lorsque le service est explicitement non utilisé. NSSM_EXIT_COUNT - Nombre de fois que l'application a quitté. NSSM_EXITCODE - Code de sortie de l'application. Peut être vide si l'application est toujours en cours d'exécution ou n'a pas encore commencé. NSSM_RUNTIME - Nombre de millisecondes pour lesquelles l'exécutable NSSM a été en cours d'exécution. NSSM_APPLICATION_RUNTIME - Nombre de millisecondes pour lesquelles l'application est en cours d'exécution depuis son démarrage. Peut être vide si la demande n'a pas encore été démarrée.
Les versions futures de NSSM peuvent fournir plus de variables d'environnement, auquel cas NSSM_HOOK_VERSION sera défini sur un nombre plus élevé.
Les crochets sont configurés en créant des valeurs String (reg_expand_sz) dans le registre nommé d'après l'action de crochet et placée sous HKLM System CurrentControlset Services <Serfe> Paramètres Appvents <events>.
Par exemple, le service pourrait être configuré pour redémarrer lorsque le système reprend à partir de la veille en définissant des appvents Power CV à:
%NSSM_EXE% restart %NSSM_SERVICE_NAME%
Pour définir un crochet sur la ligne de commande, utilisez
nssm set <servicename> AppEvents <event>/<action> <command>
Notez que NSSM interrompra le démarrage de l'application si un code de départ / pré-Hook renvoie le code de sortie de 99.
Un service exécutera normalement des crochets dans l'ordre suivant:
Démarrer / pré démarrer / publier STOP / PRE SORKING / POST
Si l'application se bloque et est redémarrée par NSSM, l'ordre pourrait être:
Démarrer / pré démarrer / publier la sortie / post start / pré start / post stop / pre sort / post
Si NSSM redirige STDOUT ou STDERR, il peut être configuré pour rediriger la sortie de tous les crochets qu'il exécute. Définissez les produits d'approvisionnement à 1 pour permettre cette fonctionnalité. Un crochet peut bien sûr rediriger ses propres E / S indépendamment du NSSM.
NSSM peut modifier les paramètres des services existants avec la même interface graphique qui est utilisée pour les installer. Courir
nssm edit <servicename>
Pour élever l'interface graphique.
NSSM offre des capacités d'édition limitées pour des services autres que ceux qui exécutent le NSSM lui-même. Lorsque NSSM est invité à modifier un service qui n'a pas les paramètres de registre de l'APP * décrits ci-dessus, l'interface graphique permettra d'éditer uniquement les paramètres système tels que le nom et la description de l'affichage du service.
NSSM peut récupérer ou définir des paramètres de service individuels à partir de la ligne de commande. En général, la syntaxe est la suivante, mais voir ci-dessous pour les exceptions.
nssm get <servicename> <parameter>
nssm set <servicename> <parameter> <value>
Les paramètres peuvent également être réinitialisés à leurs valeurs par défaut.
nssm reset <servicename> <parameter>
Les noms de paramètres reconnus par NSSM sont les mêmes que les noms d'entrée de registre décrits ci-dessus, par exemple AppDirectory.
NSSM offre des capacités d'édition limitées pour des services autres que ceux qui exécutent le NSSM lui-même. Les paramètres reconnus sont les suivants:
Description: Description du service. DisplayName: Nom d'affichage du service. Environnement: Environnement fusionné de service. ImagePath: chemin vers l'exécutable de service. Nom d'objet: compte utilisateur qui exécute le service. Nom: Nom de la clé de service. Démarrer: Service Type de démarrage. Type: type de service.
Ceux-ci correspondent aux valeurs de registre sous la clé du service HKLM System CurrentControlset Services <fread>.
Notez que NSSM concatera tous les arguments transmis sur la ligne de commande avec des espaces pour former la valeur à définir. Ainsi, les deux invocations suivantes auraient le même effet.
nssm set <servicename> Description "NSSM managed service"
nssm set <servicename> Description NSSM managed service
Les paramètres de l'Appenvironment, de l'AppenvironmentExtra et de l'environnement reconnaissent un argument supplémentaire lors de l'interrogation de l'environnement. La syntaxe suivante imprimera toutes les variables d'environnement supplémentaires configurées pour un service
nssm get <servicename> AppEnvironmentExtra
tandis que la syntaxe ci-dessous imprimera uniquement la valeur de la variable ClassPath si elle est configurée dans le bloc d'environnement, ou la chaîne vide si elle n'est pas configurée.
nssm get <servicename> AppEnvironmentExtra CLASSPATH
Lors de la définition d'un bloc d'environnement, chaque variable doit être spécifiée en tant que paire de valeurs de clé = dans des arguments de ligne de commande séparés. Par exemple:
nssm set <servicename> AppEnvironment CLASSPATH=C:Classes TEMP=C:Temp
Alternativement, la touche peut être préfixée avec un symbole A + ou - pour ajouter ou supprimer une paire du bloc.
Les deux lignes suivantes définissent le chemin de classe et la température:
nssm set <servicename> AppEnvironment CLASSPATH=C:Classes
nssm set <servicename> AppEnvironment +TEMP=C:Temp
Si la touche est déjà présente, la spécification + la touche remplacera la valeur tout en préservant l'ordre des clés:
nssm set <servicename> AppEnvironment +CLASSPATH=C:NewClasses
La syntaxe suivante supprime une seule variable du bloc tout en laissant toutes les autres variables en place.
nssm set <servicename> AppEnvironment -TEMP
Spécification -Key = Value Supprimera la variable uniquement si la valeur existante correspond.
La syntaxe suivante ne supprimerait pas la température = C: Temp
nssm set <servicename> AppEnvironment -TEMP=C:WorkTemporary
Les symboles + et - sont des caractères valides dans les variables d'environnement. La syntaxe: key = valeur est équivalente à key = valeur et peut être utilisée pour définir des variables qui commencent par +/- ou pour réinitialiser explicitement le bloc dans un script:
nssm set <servicename> AppEnvironment :CLASSPATH=C:Classes
nssm set <servicename> AppEnvironment +TEMP=C:Temp
Le paramètre AppExit nécessite un argument supplémentaire spécifiant le code de sortie pour obtenir ou définir. L'action par défaut peut être spécifiée avec la chaîne par défaut.
Par exemple, pour obtenir l'action de sortie par défaut pour un service, vous devez exécuter
nssm get <servicename> AppExit Default
Pour obtenir l'action de sortie lorsque l'application sort avec le code de sortie 2, exécutez
nssm get <servicename> AppExit 2
Notez que si aucune action explicite n'est configurée pour un code de sortie spécifié, NSSM imprimera l'action de sortie par défaut.
Pour définir Configurer le service pour s'arrêter lorsque l'application sort avec un code de sortie de 2, exécutez
nssm set <servicename> AppExit 2 Exit
Le paramètre Appriority est utilisé pour définir la classe prioritaire de l'application gérée. Les priorités valides sont les suivantes:
Realtime_priority_class high_pririty_class ci-dessus_normal_pririty_class normal_priority_class inférieur_normal_pririty_class idle_pririty_class
Les paramètres DependongRoup et DelaSonService sont utilisés pour interroger ou définir les dépendances du service. Lors de la définition des dépendances, chaque service de service ou de service (précédé du symbole +) doit être spécifié dans des arguments de ligne de commande distincts. Par exemple:
nssm set <servicename> DependOnService RpcSs LanmanWorkstation
Alternativement, le nom de dépendance peut être préfixé avec un symbole + ou - pour ajouter ou supprimer une dépendance.
Les deux lignes suivantes définissent les dépendances sur RPCSS et LanManWorkStation:
nssm set <servicename> DependOnService RpcSs
nssm set <servicename> DependOnService +LanmanWorkstation
La syntaxe Follwing supprime la dépendance des RPCS:
nssm set <servicename> DependOnService -RpcSs
Les groupes de services devraient, à proprement parler, être préfixés avec le symbole +. Pour spécifier une seule dépendance à un groupe, le symbole + peut être préfixé avec le symbole:.
Les lignes suivantes sont équivalentes, et chacune définit une dépendance uniquement à NetBiosgroup:
nssm set <servicename> DependOnGroup NetBIOSGroup
nssm set <servicename> DependOnGroup :NetBIOSGroup
nssm set <servicename> DependOnGroup :+NetBIOSGroup
Alors que ces lignes ajoutent à toutes les dépendances existantes:
nssm set <servicename> DependOnGroup +NetBIOSGroup
nssm set <servicename> DependOnGroup ++NetBIOSGroup
Le paramètre de nom ne peut être interrogé, pas défini. Il renvoie le nom de la clé de registre du service. Il peut être utile de savoir si vous profitez du fait que vous pouvez remplacer le nom d'affichage du service n'importe où où la syntaxe demande.
Le paramètre ObjectName ne nécessite un argument supplémentaire que lors de la définition d'un nom d'utilisateur. L'argument supplémentaire est le mot de passe de l'utilisateur.
Pour récupérer le nom d'utilisateur, courez
nssm get <servicename> ObjectName
Pour définir le nom d'utilisateur et le mot de passe, exécutez
nssm set <servicename> ObjectName <username> <password>
Notez que les règles de la concaténation des arguments s'appliquent toujours. L'invocation suivante est valide et aura l'effet attendu.
nssm set <servicename> ObjectName <username> correct horse battery staple
Les noms d'utilisateur bien connus suivants n'ont pas besoin d'un mot de passe. Le paramètre de mot de passe peut être omis lors de leur utilisation:
"LocalSystem" AKA "System" AKA "NT Authority System" "LocalService" AKA "Service local" AKA "NT Authority Local Service" "NetworkService" AKA "Network Service" AKA "NT Authority Network Service" Virtual Service Account "NT Service <ServiceName>"
Le paramètre de démarrage est utilisé pour interroger ou définir le type de démarrage du service. Les types de startups de service valides sont les suivants:
Service_auto_start: démarrage automatique au démarrage. Service_delayed_start: startup retardé au démarrage. Service_demand_start: startup de service manuel. Service_Disabled: Le service est désactivé.
Notez que Service_delayed_start n'est pas pris en charge sur les versions de Windows avant Vista. NSSM définira le service sur le démarrage automatique si le démarrage retardé n'est pas disponible.
Le paramètre de type est utilisé pour interroger ou définir le type de service. NSSM reconnaît tous les types de services actuellement documentés, mais ne permettra que la définition de l'un des deux types:
Service_win32_own_process: un service autonome. C'est la valeur par défaut. Service_interactive_process: un service qui peut interagir avec le bureau.
Notez qu'un service ne peut être configuré comme interactif que s'il s'exécute sous le compte localSystem. Le moyen sûr de configurer un service interactif est en deux étapes comme suit.
nssm reset <servicename> ObjectName
nssm set <servicename> Type SERVICE_INTERACTIVE_PROCESS
NSSM propose des fonctionnalités de contrôle de service rudimentaires.
nssm start <servicename>
nssm restart <servicename>
nssm stop <servicename>
nssm status <servicename>
nssm statuscode <servicename>
La sortie de "NSSM Status" et "NSSM Statuscode" est une chaîne représentant l'état de service, par exemple Service_Running.
Le code de sortie de "Statut NSSM" sera 0 si le statut a été récupéré avec succès. Si le code de sortie n'est pas zéro, il y a eu une erreur.
Le code de sortie de "NSSM Statuscode" sera la valeur numérique de l'état de service, par exemple 4 pour Service_Running. Zéro n'est pas un code d'état de service valide. Si le code de sortie est zéro, il y a eu une erreur.
NSSM peut également supprimer les services. Courir
nssm remove <servicename>
pour supprimer un service. Vous allez provoquer une confirmation avant la suppression du service. Essayez de ne pas supprimer les services système essentiels ...
Pour supprimer un service sans confirmation de l'interface graphique, exécutez
nssm remove <servicename> confirm
Essayez de ne pas supprimer les services système essentiels ...
NSSM Journaux au journal des événements Windows. Il s'inscrit en tant que source de journal d'événements et utilise des ID d'événement uniques pour chaque type de message qu'il enregistre. Les nouvelles versions peuvent ajouter des types d'événements, mais les ID d'événements existants ne seront jamais modifiés.
En raison de la façon dont NSSM s'inscrit lui-même, vous devez savoir que vous ne pourrez peut-être pas remplacer le binaire NSSM si vous avez la visionneuse d'événements ouverte et que l'exécution de plusieurs instances de NSSM à partir de différents emplacements peut être déroutant s'ils ne sont pas tous la même version.
La commande suivante imprimera les noms de tous les services gérés par NSSM:
nssm list
Pour voir tous les services sur le système, pas seulement NSSM, utilisez la liste tout:
nssm list all
La commande suivante imprimera l'ID de processus et le chemin exécutable des processus démarrés par un service donné:
nssm processes <servicename>
Notez que si le NSSM 32 bits est exécuté sur un système 64 bits exécutant une ancienne version de Windows que Vista, il ne pourra pas interroger les chemins de processus 64 bits.
NSSM peut vider des commandes qui recréeraient la configuration d'un service. La sortie peut être collée dans un script de lot pour sauvegarder le service ou transférer vers un autre ordinateur.
nssm dump <servicename>
Étant donné que la configuration du service peut contenir des caractères qui doivent être cités ou échappés de l'invite de commande, NSSM s'efforce de produire de la sortie qui fonctionnera correctement lors de l'exécution en tant que script, en ajoutant des citations et des échappements de caret, selon le cas.
Pour faciliter la copie d'un service, la commande de vidage accepte un deuxième argument qui spécifie le nom du service à utiliser dans la sortie.
nssm dump <servicename> <newname>
Les lignes dans le vidage référenteront le service tout en affichant la configuration de.
Pour installer un serveur de tournoi Unreal:
nssm install UT2004 c:gamesut2004systemucc.exe server
Pour exécuter le serveur en tant qu'utilisateur "jeux":
nssm set UT2004 ObjectName games password
Pour configurer le serveur pour se connecter à un fichier:
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.
