NSSM
v2.25
NSSM es un programa de servicio de servicio similar a Srvany y Cygrunsrv. Puede iniciar cualquier aplicación (como la consola) como un servicio NT y reiniciará el servicio si falla por algún motivo.
NSSM también tiene un instalador y removedor de servicios gráficos.
Esta es una bifurcación de NSSM
Archivos binarios que puede encontrar en lanzamientos aquí
Código original: https://git.nssm.cc/nssm/nssm por Iain Patterson
Documentación: uso, comandos
En las notas de uso a continuación, los argumentos al programa pueden escribirse en soportes de ángulo y/o soportes cuadrados. significa que debe insertar la cadena apropiada y [] significa que la cadena es opcional. Vea los ejemplos a continuación ...
Tenga en cuenta que en todas partes aparece que puede sustituir el nombre de la pantalla del servicio.
Para instalar un servicio, ejecute
nssm install <servicename>
Se le pedirá que ingrese la ruta completa a la aplicación que desea ejecutar y cualquier opción de línea de comando para pasar a esa aplicación.
Use el System Service Manager (Services.MSC) para controlar las propiedades de servicio avanzadas, como el método de inicio y la interacción de escritorio. NSSM puede admitir estas opciones en un momento posterior ...
Para instalar un servicio, ejecute
nssm install <servicename> <application> [<options>]
NSSM intentará instalar un servicio que ejecute la aplicación con nombre con las opciones dadas (si especificó alguna).
¡No olvide adjuntar rutas en "citas" si contienen espacios!
Si desea incluir citas en las opciones, deberá "" "citar" "" las citas.
NSSM iniciará la aplicación que figura en el registro cuando lo envíe una señal de inicio y la terminará cuando envíe una señal de parada. Hasta ahora, muy parecido a Srvany. Pero NSSM es el Gerente de Servicio que no se usa y puede tomar medidas si la aplicación muere.
Sin configuración de usted, NSSM intentará reiniciarse si se da cuenta de que la aplicación murió, pero no le envió una señal de parada. NSSM seguirá intentando, deteniéndose entre cada intento, hasta que el servicio se inicie con éxito o le envíe una señal de parada.
NSSM detendrá un tiempo cada vez más largo entre los intentos de reinicio posteriores si el servicio no comienza de manera oportuna, hasta un máximo de cuatro minutos. Esto es para que no consuma una cantidad excesiva de tiempo de CPU tratando de iniciar una aplicación fallida una y otra vez. Si identifica la causa de la falla y no desea esperar, puede usar la consola de servicio de Windows (donde el servicio se mostrará en estado pausado) para enviar una señal de continuar a NSSM y volverá a intentarlo en unos segundos.
Por defecto, NSSM define "una manera oportuna" para estar dentro de los 1500 milisegundos. Puede cambiar el umbral para el servicio estableciendo el número de milisegundos como un valor reg_dword en el registro en HKLM System CurrentControlset Services <Serving> Parameters AppThrottle.
Alternativamente, NSSM puede detenerse durante una cantidad de tiempo configurable antes de intentar reiniciar la aplicación, incluso si se ejecutó con éxito durante la cantidad de tiempo especificado por AppThrottle. NSSM consultará el valor de Reg_dword en HKLM System CurrentControlset Services <Serving> Parameters ApprienteTDelay para que el número de milisegundos espere antes de intentar reiniciar. Si se establece HerprestArtDelay y se determina que la aplicación está sujeta a estrangulamiento, NSSM detendrá el servicio para el que sea más largo del retraso de reinicio configurado y el período de acelerador calculado.
Si Falta o no es válido AppRestartDelay, solo se aplicará los estranguladores.
NSSM buscará en el registro en HKLM System CurrentControlset Services <Serving> Parameters AppExit para valores de cadena (reg_expand_sz) correspondientes al código de salida de la aplicación. Si la aplicación salió con el Código 1, por ejemplo, NSSM buscará un valor de cadena en AppExit llamado "1" o, si no lo encuentra, volverá al valor AppExit (predeterminado). Puede encontrar el código de salida para la aplicación consultando el registro de eventos del sistema. NSSM registrará el código de salida cuando la aplicación salga.
Según los datos encontrados en el registro, NSSM tomará una de las tres acciones:
Si los datos de valor son "reiniciar", NSSM intentará reiniciar la aplicación como se describió anteriormente. Este es su comportamiento predeterminado.
Si los datos de valor son "ignorar", NSSM no intentará reiniciar la aplicación, pero continuará ejecutándose. Esto emula el comportamiento (generalmente indeseable) de Srvany. La consola de servicios de Windows mostraría que el servicio todavía se ejecuta a pesar de que la aplicación ha salido.
Si los datos de valor son "Salir", NSSM saldrá con gracia. La consola de servicios de Windows mostraría que el servicio se detuvo. Si desea proporcionar un control de grano más fino sobre la recuperación del servicio, debe usar este código y editar la acción de falla manualmente. Tenga en cuenta que las versiones de Windows antes de Vista no considerarán que tal salida sea una falla. En versiones anteriores de Windows, debe usar "suicidio" en su lugar.
Si los datos de valor son "suicidio", NSSM simulará un bloqueo y saldrá sin informar al administrador de servicios. Esta opción solo debe usarse para los sistemas previos a la vista donde desea aplicar una acción de recuperación de servicios. Tenga en cuenta que si la aplicación monitoreada sale con el Código 0, NSSM solo honrará una solicitud de suicidio si configura explícitamente una clave de registro para el código de salida 0. Si solo la acción predeterminada se establece en Suicidio, NSSM saldrá con gracia.
NSSM puede establecer la clase de prioridad de la aplicación administrada. NSSM buscará en el registro en HKLM System CurrentControlset Services <Serving> Parámetros para la AppRiority de entrada Reg_dword. Los valores válidos corresponden a argumentos a setPriorityClass (). Si faltan appRiority (), la aplicación se lanzará con prioridad normal.
NSSM puede establecer la afinidad de la CPU de la aplicación administrada. NSSM buscará en el registro en HKLM System CurrentControlset Services <Serving> Parámetros para la entrada Reg_sz AppAffinity. Debe especificar una lista de ID de procesador de índice cero, separada por comas. Opcionalmente, se puede especificar una gama de procesadores con un tablero. No se permiten otros caracteres en la cadena.
Por ejemplo, para especificar el primero; segundo; Tercera y quinta CPU, una appaffinidad apropiada sería 0-2,4.
Si falta appaffinity o no es válido, NSSM no intentará restringir la aplicación a CPU específicas.
Tenga en cuenta que la versión de 64 bits de NSSM puede configurar un máximo de 64 CPU de esta manera y que la versión de 32 bits puede configurar un maxium de 32 CPU incluso cuando se ejecuta en ventanas de 64 bits.
Al detener un servicio, NSSM intentará varios métodos diferentes para matar la aplicación monitoreada, cada uno de los cuales puede deshabilitarse si es necesario.
First NSSM intentará generar un evento de control-C y enviarlo a la consola de la aplicación. Los scripts de lotes o las aplicaciones de la consola pueden interceptar el evento y cerrar con gracia. Las aplicaciones GUI no tienen consolas y no responderán a este método.
En segundo lugar, NSSM enumerará todas las ventanas creadas por la aplicación y les enviará un mensaje WM_CLOSE, solicitando una salida elegante.
En tercer lugar, NSSM enumerará todos los hilos creados por la aplicación y les enviará un mensaje WM_QUIT, solicitando una salida elegante. No todos los hilos de aplicaciones tienen colas de mensajes; aquellos que no responderán a este método.
Finalmente, NSSM llamará a TermenateProcess () para solicitar que el sistema operativo finalice por la fuerza la aplicación. TerminateProcess () no puede ser atrapado o ignorado, por lo que en la mayoría de las circunstancias la solicitud será asesinada. Sin embargo, no hay garantía de que tenga la oportunidad de realizar operaciones de ordenación antes de que salga.
Cualquiera o todos los métodos anteriores puede estar deshabilitado. NSSM buscará el valor de registro HKLM System CurrentControlSet Services <Serving> Parameters AppStopMethodSkip que debe ser de tipo Reg_dword establecido en un campo de bits que describe qué métodos no se deben aplicar.
Si AppStopMethodskip incluye 1, los eventos de control-C no se generarán. Si AppStopMethodskip incluye 2, no se publicarán mensajes WM_CLOSE. Si AppStopMethodskip incluye 4, no se publicarán mensajes WM_QUIT. Si AppStopMethodskip incluye 8, no se llamará a SerminateProcess ().
Si, por ejemplo, sabía que una aplicación no respondía a los eventos de control-C y no tenía una cola de mensajes de hilo, podría establecer AppStopMethodskip a 5 y NSSM no intentaría usar esos métodos para detener la aplicación.
Tenga mucho cuidado al incluir 8 en el valor de AppStopMethodskip. Si NSSM no llama a TermenateProcess (), es posible que la aplicación no salga cuando el servicio se detiene.
Por defecto, NSSM permitirá que los procesos 1500 ms respondan a cada uno de los métodos descritos anteriormente antes de continuar con el siguiente. El tiempo de espera se puede configurar por método mediante la creación de entradas de Reg_dword en el registro en HKLM System CurrentControlset Services <Serving> Parameters.
AppStopMethodConsole AppStopMethodwindow AppStopMethodthreads
Cada valor debe establecerse en el número de milisegundos para esperar. Tenga en cuenta que el tiempo de espera se aplica a cada proceso en el árbol de proceso de la aplicación, por lo que el tiempo real de apagado puede ser más largo que la suma de todos los tiempos de espera configurados si la aplicación genera múltiples subprocesos.
Para omitir la aplicación de los métodos de detención anteriores a todos los procesos en el árbol de proceso de la aplicación, aplicándolos solo al proceso de aplicación original, establezca el valor de registro HKLM System CurrentControlset Services <Serving> Parameters AppKillProcesStree, que debería ser de tipo reg_dword, a 0.
De manera predeterminada, NSSM creará una ventana de consola para que las aplicaciones que sean capaces de leer la entrada del usuario puedan hacerlo, sujeto al servicio que se permita interactuar con el escritorio.
La creación de la consola se puede suprimir configurando el entero (reg_dword) HKLM System CurrentControlSet Services <Service> Parameters AppNoconsole Registry Value a 1.
NSSM puede redirigir la E/S de la aplicación administrada a cualquier ruta capaz de ser abrida por CreateFile (). Esto permite, por ejemplo, capturar la salida de registro de una aplicación que de otra manera solo escribiría en la consola o aceptar la entrada de un puerto serie.
NSSM buscará en el registro en HKLM System CurrentControlset Services <Serving> Parámetros para las claves correspondientes a los argumentos a CreateFile (). Todos son opcionales. Si no se da una ruta para una transmisión en particular, no será redirigido. Si se da una ruta, pero se omite cualquiera de los otros valores, recibirán valores predeterminados sensatos.
Appstdin: ruta para recibir la entrada. AppStDout: ruta para recibir la salida. AppStderr: ruta para recibir la salida de error.
Los parámetros para CreateFile () están proporcionando los valores "AppStDinSharemode", "AppStDinCreationDisposition" y "AppStDinFlagSandattributes" (y análogos para STDOUT y STDERR).
En general, si desea que el servicio registre su salida, establezca AppStDout y Appstderr en la misma ruta, por ejemplo, C: Users public Service.log, y debería funcionar. Recuerde, sin embargo, que la ruta debe ser accesible para el usuario que ejecuta el servicio.
Cuando se usa la redirección de E/S, NSSM puede rotar los archivos de salida existentes antes de abrir STDOUT y/o STDERR. Un archivo existente se cambiará el nombre de un sufijo basado en el último tiempo de escritura del archivo, a MilliseCond Precision. Por ejemplo, el archivo nssm.log podría girarse a NSSM-20131221T113939.457.log.
NSSM buscará en el registro en HKLM System CurrentControlset Services <Serving> Parámetros para entradas Reg_dword que controlan cómo ocurre la rotación.
Si Falta o se establece APROTATEFILES en 0, la rotación está deshabilitada. Cualquier valor distinto de cero permite la rotación.
Si ApprotateConds no es cero, un archivo no se girará si su último tiempo de escritura es menor que el número dado de segundos en el pasado.
Si ApprotateBytes no es cero, un archivo no se girará si es más pequeño que el número dado de bytes. Los tamaños de archivo de 64 bits se pueden manejar estableciendo un valor distinto de cero de ApprotateByTeshigh.
Si ApprotatedLay no es Zero, NSSM se detendrá para el número dado de milisegundos después de la rotación.
Si AppStDoutCopyAndtruncate o AppstderrCopyAndtruncate no son cero, el archivo STDOUT (o STDERR respectivamente) se girará primero tomando una copia del archivo y luego truncando el archivo original al tamaño cero. Esto permite que NSSM gire los archivos que se mantienen abiertos por otros procesos, evitando que el MudeFile habitual () tenga éxito. Tenga en cuenta que el proceso de copia puede llevar algún tiempo si el archivo es grande y consumirá temporalmente el doble de espacio de disco que el archivo original. Tenga en cuenta también que las aplicaciones que leen el archivo de registro pueden no notar que el tamaño del archivo cambió. Usar esta opción junto con ApprotatedLay puede ayudar en ese caso.
La rotación es independiente de los parámetros createFile () utilizados para abrir los archivos. Se girarán independientemente de si NSSM los habría agregado o reemplazado.
NSSM también puede rotar archivos que alcanzan el umbral de tamaño configurado mientras el servicio se está ejecutando. Además, puede activar una rotación a pedido ejecutando el comando
nssm rotate <servicename>
Las rotaciones a pedido ocurrirán después de que se lea la próxima línea de datos de la aplicación administrada, independientemente del valor de ApprotateBytes. Tenga en cuenta que si la aplicación no es particularmente detallada, la rotación puede no ocurrir por algún tiempo.
Para habilitar la rotación en línea y bajo demanda, establezca ApprotateOnline en un valor distinto de cero.
Tenga en cuenta que la rotación en línea requiere que NSSM intercepte la E/S de la aplicación y cree los archivos de salida en su nombre. Esto es más complejo y propenso a errores que simplemente redirigir las transmisiones de E/S antes de iniciar la aplicación. Por lo tanto, la rotación en línea no está habilitada de forma predeterminada.
Al redirigir la salida, NSSM puede prefijo cada línea de salida con una marca de tiempo de precisión de milisegundos, por ejemplo:
2016-09-06 10:17:09.451 Pipeline main started
Para habilitar el prefijo de la marca de tiempo, establezca ApptimeStAMPLOG en un valor distinto de cero.
El prefijo se aplica tanto a STDOUT como a Stderr. El prefijo requiere interceptar las E/S de la aplicación de la misma manera que lo hace la rotación en línea. Si la rotación del registro y el prefijo de marca de tiempo están habilitados, la rotación estará en línea.
NSSM puede reemplazar o agregar al entorno de la aplicación administrada. Dos valores de registro de cadenas de valores múltiples (REG_MULTI_SZ) se reconocen en HKLM System CurrentControlSet Services <Serving> Parameters.
Appenvironment define una lista de variables de entorno que anulará el entorno del servicio. AppenvironmentalExtra define una lista de variables de entorno que se agregarán al entorno del servicio.
Cada entrada en la lista debe ser del valor de la tecla de formulario = valor. Es posible omitir el valor pero el símbolo = es obligatorio.
Las variables de entorno enumeradas tanto en Appenvironment como en AppenvironmentalExtra están sujetas a una expansión normal, por lo que es posible, por ejemplo, actualizar la ruta del sistema configurando "ruta = c: bin;%ruta%" en AppenVironmentExtra. Las variables se amplían en el orden en que aparecen, por lo que si desea incluir el valor de una variable en otra variable, debe declarar primero la dependencia.
Debido a que las variables definidas en el apéndice anulan el entorno existente, no es posible referirse a ninguna variable que se definiera previamente.
Por ejemplo, el siguiente bloque de Appenvironment:
PATH=C:WindowsSystem32;C:Windows
PATH=C:bin;%PATH%
Resultaría en una ruta de "c: bin; c: windows system32; c: windows" como se esperaba.
Mientras que el siguiente bloque de Appenvironment:
PATH=C:bin;%PATH%
Daría como resultado una ruta que contiene solo c: bin y probablemente cause que la aplicación no se inicie.
La mayoría de las personas querrán usar AppenvironmentalExtra exclusivamente. Srvany solo admite el apéndice.
A partir de la versión 2.25, NSSM analiza Appenvironment y AppenvironmentalExtra en sí, antes de leer cualquier otro valor de registro. Como resultado, ahora es posible referirse a variables de entorno personalizadas en la aplicación, AppDirectory y otros parámetros.
Todos los servicios de Windows se pueden pasar variables de entorno adicionales creando un valor de registro de cadena múltiple (reg_multi_sz) llamado HLKM System CurrentControlset Services <Serving> Environment.
El contenido de este bloque de entorno se fusionará en el entorno del sistema antes de que comience el servicio.
Sin embargo, tenga en cuenta que el entorno fusionado se clasificará alfabéticamente antes de ser procesado. Esto significa que en la práctica no puede establecer, por ejemplo, Dir =%ProgramFiles%en el bloque de medio ambiente porque el entorno transmitido al servicio no habrá definido%de programas de programas para cuando llegue el%de%Dir%. Las variables de entorno definidas en AppenvironmentalExtra no sufren esta limitación.
A partir de la versión 2.25, NSSM puede obtener y establecer el bloque de entorno utilizando comandos similares a:
nssm get <servicename> Environment
Vale la pena reiterar que el bloque ambiente está disponible para todos los servicios de Windows, no solo los servicios NSSM.
El entorno NSSM pasa a la aplicación depende de cómo se configuran varios valores de registro. El siguiente flujo describe cómo se modifica el entorno.
Por defecto: el servicio hereda el entorno del sistema.
Si se define entorno: el contenido del entorno se fusiona en el medio ambiente.
Si se define parámetros Appenvironment: el servicio hereda el entorno especificado en Appenvironment.
Si se define parámetros appenvironmentExtra: el contenido de AppenvironmentalExtra se agregan al entorno.
Tenga en cuenta que el apéndice anula el entorno del sistema y el bloque de entorno fusionado. Tenga en cuenta también que se garantiza que AppenvironmentalExtra se agregará al entorno de inicio si se define.
NSSM puede ejecutar comandos configurables por el usuario en respuesta a eventos de aplicación. Estos comandos se denominan "ganchos" a continuación.
Todos los ganchos son opcionales. Cualquier gancho que se ejecute se lanzarán con el entorno configurado para el servicio. NSSM colocará variables adicionales en el entorno que los ganchos pueden consultar para aprender cómo y por qué se les llamó.
Los ganchos se clasifican por evento y acción. Algunos ganchos se ejecutan sincrónicamente y otros se ejecutan asincrónicamente. Los ganchos prefijados con un *asterisco se ejecutan sincrónicamente. NSSM esperará a que estos ganchos completen antes de continuar su trabajo. Sin embargo, tenga en cuenta que todos los ganchos están sujetos a una fecha límite después de la cual serán asesinados, independientemente de si se ejecutan de manera asincrónica o no.
Evento: Inicio: activado cuando se solicita al servicio que se inicie. *Acción: Pre - llamado antes de que NSSM intente iniciar la aplicación. Acción: POST: llamado después de que la aplicación comience con éxito.
Evento: parar: activado cuando se solicita al servicio que se detenga. *Acción: Pre - llamado antes de que NSSM intente matar la aplicación.
Evento: Salir: activado cuando la aplicación sale. *Acción: Post: llamado después de que NSSM haya limpiado la aplicación.
Evento: Rotar: activado cuando se solicita la rotación del registro en línea. *Acción: pre - llamado antes de que NSSM gire los registros. Acción: Post: llamado después de que NSSM gira los registros.
Evento: Acción de energía: Cambiar: llamado cuando el estado de potencia del sistema ha cambiado. Acción: Reanudar: llamado cuando el sistema se ha reanudado del espera.
Tenga en cuenta que no hay parada/gancho post. Esto se debe a que la salida/publicación se llama cuando la aplicación sale, independientemente de si lo hizo en respuesta a una solicitud de cierre del servicio. Stop/pre solo se llama antes de un elegante intento de cierre.
NSSM establece la variable de entorno NSSM_HOOK_VERSION a un número positivo. Los ganchos pueden verificar el valor del número para determinar qué otras variables de entorno están disponibles para ellos.
Si NSSM_Hook_Version es 1 o mayor, se proporcionan estas variables:
NSSM_EXE - Ruta a NSSM en sí. NSSM_Configuration: cree información para el ejecutable NSSM, por ejemplo, depuración de 64 bits. NSSM_Version - Versión del ejecutable NSSM. NSSM_Build_Date - Fecha de compilación de NSSM. NSSM_PID - ID de proceso del ejecutable de ejecución de NSSM. NSSM_Deadline - Fecha límite de milisegundos después de lo cual NSSM matará el gancho si todavía está funcionando. NSSM_Service_Name - Nombre del servicio controlado por NSSM. NSSM_Service_DisplayName - Nombre de visualización del servicio. NSSM_COMMAND_LINE - Línea de comando utilizada para iniciar la aplicación. NSSM_APPLICATION_PID - ID de proceso del proceso de aplicación principal. Puede estar en blanco si el proceso no se está ejecutando. NSSM_EVENT - Clase de eventos activando el gancho. NSSM_ACTION - Acción del evento que dispara el gancho. NSSM_TRIGG - Control de servicio activando el gancho. Puede estar en blanco si el gancho no fue activado por un control de servicio, por ejemplo, salir/post. NSSM_LAST_CONTROL - Último control de servicio manejado por NSSM. NSSM_START_REQUESTSE_COUNT - Número de veces que se solicitó la aplicación para comenzar. NSSM_START_COUNT - Número de veces la aplicación comenzó correctamente. NSSM_THROTTLE_COUNT - Número de veces la aplicación se ejecutó por menos del período del acelerador. Restablecer a cero en el inicio exitoso o cuando el servicio se desactiva explícitamente. NSSM_EXIT_COUNT - Número de veces que salió la aplicación. NSSM_EXITCODE - Código de salida de la aplicación. Puede estar en blanco si la aplicación todavía se está ejecutando o aún no ha comenzado. NSSM_Runtime: número de milisegundos para los cuales el ejecutable de NSSM se ha estado ejecutando. NSSM_APplication_Runtime: número de milisegundos para los cuales la aplicación se ha estado ejecutando desde la última vez que comenzó. Puede estar en blanco si la aplicación aún no se ha iniciado.
Las versiones futuras de NSSM pueden proporcionar más variables de entorno, en cuyo caso NSSM_HOOK_VERSION se establecerá en un número más alto.
Los ganchos se configuran creando valores de cadena (reg_expand_sz) en el registro que lleva el nombre de la acción de gancho y se colocan en HKLM System CurrentControlset Services <Serving> Parameters Appevents <vent>.
Por ejemplo, el servicio podría configurarse para reiniciar cuando el sistema se reanuda desde Standby configurando Appevents Power Reano a:
%NSSM_EXE% restart %NSSM_SERVICE_NAME%
Para establecer un gancho en la línea de comando, use
nssm set <servicename> AppEvents <event>/<action> <command>
Tenga en cuenta que NSSM abortará el inicio de la aplicación si un código de salida inicial/previo devuelve el código de salida de 99.
Un servicio normalmente ejecutará ganchos en el siguiente orden:
Inicio/Pre inicio/POST STOP/Pre EXIT/POST
Si la aplicación se bloquea y es reiniciada por NSSM, el pedido podría ser:
Inicio/pre inicio/post salir/post inicio/pre inicio/post stop/pre -sale/post
Si NSSM está redirigiendo stdout o stderr, se puede configurar para redirigir la salida de cualquier gancho que ejecute. Establezca Apcredirecthooks en 1 para habilitar esa funcionalidad. Un gancho puede, por supuesto, redirigir su propia E/S independientemente de NSSM.
NSSM puede editar la configuración de los servicios existentes con la misma GUI que se utiliza para instalarlos. Correr
nssm edit <servicename>
para mencionar la GUI.
NSSM ofrece capacidades de edición limitadas para servicios distintos a los que se ejecutan en sí mismo. Cuando se le pide a NSSM que edite un servicio que no tenga la configuración del registro de la aplicación* descrita anteriormente, la GUI permitirá la edición de la configuración del sistema solo como el nombre y la descripción de la pantalla del servicio.
NSSM puede recuperar o establecer parámetros de servicio individuales desde la línea de comando. En general, la sintaxis es la siguiente, aunque vea a continuación las excepciones.
nssm get <servicename> <parameter>
nssm set <servicename> <parameter> <value>
Los parámetros también se pueden restablecer a sus valores predeterminados.
nssm reset <servicename> <parameter>
Los nombres de parámetros reconocidos por NSSM son los mismos que los nombres de entrada del registro descritos anteriormente, por ejemplo, AppDirectory.
NSSM ofrece capacidades de edición limitadas para servicios distintos a los que se ejecutan en sí mismo. Los parámetros reconocidos son los siguientes:
Descripción: Descripción del servicio. DisplayName: Service Nombre de pantalla. Medio ambiente: Servicio Fusionado Entorno. ImagePath: ruta al ejecutable del servicio. ObjectName: cuenta de usuario que ejecuta el servicio. Nombre: Nombre de la clave de servicio. Inicio: Tipo de inicio del servicio. Tipo: Tipo de servicio.
Estos corresponden a los valores de registro bajo la clave del servicio HKLM System CurrentControlset Services <Serving>.
Tenga en cuenta que NSSM concatenará todos los argumentos que se transmiten en la línea de comando con los espacios para formar el valor para establecer. Por lo tanto, las siguientes dos invocaciones tendrían el mismo efecto.
nssm set <servicename> Description "NSSM managed service"
nssm set <servicename> Description NSSM managed service
Los parámetros del Appenubirment, AppenvironmentalExtra y el entorno reconocen un argumento adicional al consultar el entorno. La siguiente sintaxis imprimirá todas las variables de entorno adicionales configuradas para un servicio
nssm get <servicename> AppEnvironmentExtra
Mientras que la sintaxis a continuación imprimirá solo el valor de la variable classpath si está configurada en el bloque de entorno, o la cadena vacía si no está configurada.
nssm get <servicename> AppEnvironmentExtra CLASSPATH
Al establecer un bloque de entorno, cada variable debe especificarse como un par de valores clave en argumentos de línea de comandos separados. Por ejemplo:
nssm set <servicename> AppEnvironment CLASSPATH=C:Classes TEMP=C:Temp
Alternativamente, la tecla se puede prefijo con un símbolo + o - para agregar o eliminar un par del bloque.
Las siguientes dos líneas establecen classpath y temp:
nssm set <servicename> AppEnvironment CLASSPATH=C:Classes
nssm set <servicename> AppEnvironment +TEMP=C:Temp
Si la clave ya está presente, especificar +la tecla anulará el valor al preservar el orden de las claves:
nssm set <servicename> AppEnvironment +CLASSPATH=C:NewClasses
La siguiente sintaxis elimina una sola variable del bloque mientras deja cualquier otra variable en su lugar.
nssm set <servicename> AppEnvironment -TEMP
Especificar -key = valor eliminará la variable solo si el valor existente coincide.
La siguiente sintaxis no eliminaría temp = c: temp
nssm set <servicename> AppEnvironment -TEMP=C:WorkTemporary
Los símbolos + y - son caracteres válidos en las variables de entorno. La sintaxis: Key = Value es equivalente a Key = Value y puede usarse para establecer variables que comienzan con +/- o para restablecer explícitamente el bloque en un script:
nssm set <servicename> AppEnvironment :CLASSPATH=C:Classes
nssm set <servicename> AppEnvironment +TEMP=C:Temp
El parámetro AppExit requiere un argumento adicional que especifique el código de salida para obtener o establecer. La acción predeterminada se puede especificar con la cadena predeterminada.
Por ejemplo, para obtener la acción de salida predeterminada para un servicio que debe ejecutar
nssm get <servicename> AppExit Default
Para obtener la acción de salida cuando la aplicación sale con el código de salida 2, ejecute
nssm get <servicename> AppExit 2
Tenga en cuenta que si no se configura ninguna acción explícita para un código de salida especificado, NSSM imprimirá la acción de salida predeterminada.
Para configurar configurar el servicio para detenerse cuando la aplicación salga con un código de salida de 2, ejecute
nssm set <servicename> AppExit 2 Exit
El parámetro de appRiority se utiliza para establecer la clase de prioridad de la aplicación administrada. Las prioridades válidas son las siguientes:
RealTime_Priority_Class High_priority_class arriba_normal_priority_class Normal_priority_class debajo de_normal_priority_class Idle_priority_class
Los parámetros DependAgroup y Dependservice se utilizan para consultar o establecer las dependencias para el Servicio. Al establecer dependencias, cada servicio o grupo de servicio (precedido con el símbolo +) debe especificarse en argumentos de línea de comandos separados. Por ejemplo:
nssm set <servicename> DependOnService RpcSs LanmanWorkstation
Alternativamente, el nombre de la dependencia se puede prefijo con un símbolo A + o - para agregar o eliminar una dependencia respectivamente.
Las siguientes dos líneas establecen dependencias en RPCSS y LanmanWorkStation:
nssm set <servicename> DependOnService RpcSs
nssm set <servicename> DependOnService +LanmanWorkstation
La sintaxis de Follwing elimina la dependencia de RPCSS:
nssm set <servicename> DependOnService -RpcSs
Los grupos de servicio deberían, estrictamente hablando, tener prefijo con el símbolo +. Para especificar una sola dependencia en un grupo, el símbolo + se puede prefijo con el símbolo:
Las siguientes líneas son equivalentes, y cada una establece una dependencia solo en NetBiosgroup:
nssm set <servicename> DependOnGroup NetBIOSGroup
nssm set <servicename> DependOnGroup :NetBIOSGroup
nssm set <servicename> DependOnGroup :+NetBIOSGroup
Mientras que estas líneas se suman a cualquier dependencia existente:
nssm set <servicename> DependOnGroup +NetBIOSGroup
nssm set <servicename> DependOnGroup ++NetBIOSGroup
El parámetro de nombre solo se puede consultar, no establecido. Devuelve el nombre de clave de registro del servicio. Esto puede ser útil saber si aprovecha el hecho de que puede sustituir el nombre de la pantalla del servicio en cualquier lugar donde la sintaxis solicite.
El parámetro ObjectName requiere un argumento adicional solo al establecer un nombre de usuario. El argumento adicional es la contraseña del usuario.
Para recuperar el nombre de usuario, ejecutar
nssm get <servicename> ObjectName
Para establecer el nombre de usuario y la contraseña, ejecute
nssm set <servicename> ObjectName <username> <password>
Tenga en cuenta que las reglas de concatenación de argumentos aún se aplican. La siguiente invocación es válida y tendrá el efecto esperado.
nssm set <servicename> ObjectName <username> correct horse battery staple
Los siguientes nombres de usuario conocidos no necesitan una contraseña. El parámetro de contraseña se puede omitir al usarlos:
"LocalSystem" AKA "System" AKA "NT Authority System" "LocalService" también conocido como "Servicio local", también conocido como "Autoridad NT Servicio local" "NetworkService" AKA "Servicio de red" AKA "NT Authority Network Service" Virtual Service cuenta "NT Service <ServiceName>"
El parámetro de inicio se utiliza para consultar o establecer el tipo de inicio del servicio. Los tipos de inicio de servicio válidos son los siguientes:
Servicio_auto_start: inicio automático en el arranque. Servicio_delayed_start: inicio retrasado en el arranque. Servicio_demand_start: inicio del servicio manual. Servicio_disable: el servicio está deshabilitado.
Tenga en cuenta que Service_Delayed_Start no es compatible con versiones de Windows antes de Vista. NSSM establecerá el servicio en inicio automático si el inicio retrasado no está disponible.
El parámetro de tipo se utiliza para consultar o establecer el tipo de servicio. NSSM reconoce todos los tipos de servicio actualmente documentados, pero solo permitirá establecer uno de los dos tipos:
Servicio_win32_own_process: un servicio independiente. Este es el valor predeterminado. Servicio_interactive_process: un servicio que puede interactuar con el escritorio.
Tenga en cuenta que un servicio solo puede configurarse como interactivo si se ejecuta en la cuenta de LocalSystem. La forma segura de configurar un servicio interactivo es en dos etapas de la siguiente manera.
nssm reset <servicename> ObjectName
nssm set <servicename> Type SERVICE_INTERACTIVE_PROCESS
NSSM ofrece funciones de control de servicio rudimentarias.
nssm start <servicename>
nssm restart <servicename>
nssm stop <servicename>
nssm status <servicename>
nssm statuscode <servicename>
La salida del "estado NSSM" y "NSSM Statuscode" es una cadena que representa el estado de servicio, por ejemplo, Service_Running.
El código de salida del "estado NSSM" será 0 si el estado se recuperó con éxito. Si el código de salida no es cero, hubo un error.
El código de salida de "NSSM Statuscode" será el valor numérico del estado de servicio, por ejemplo, 4 para Service_Running. Zero no es un código de estado de servicio válido. Si el código de salida es cero hubo un error.
NSSM también puede eliminar los servicios. Correr
nssm remove <servicename>
para eliminar un servicio. Se le solicitará la confirmación antes de que se elimine el servicio. Trate de no eliminar los servicios del sistema esencial ...
Para eliminar un servicio sin confirmación de la GUI, ejecute
nssm remove <servicename> confirm
Trate de no eliminar los servicios del sistema esencial ...
NSSM registra el registro de eventos de Windows. Se registra como una fuente de registro de eventos y utiliza ID de evento únicos para cada tipo de mensaje que registra. Las nuevas versiones pueden agregar tipos de eventos, pero las ID de eventos existentes nunca se cambiarán.
Debido a la forma en que NSSM se registra en sí, debe tener en cuenta que es posible que no pueda reemplazar el binario NSSM si tiene el visor de eventos abierto y que ejecutar múltiples instancias de NSSM desde diferentes ubicaciones puede ser confuso si no son la misma versión.
El siguiente comando imprimirá los nombres de todos los servicios administrados por NSSM:
nssm list
Para ver todos los servicios en el sistema, no solo los de NSSM, la lista de uso todos:
nssm list all
El siguiente comando imprimirá la identificación del proceso y la ruta ejecutable de los procesos iniciados por un servicio determinado:
nssm processes <servicename>
Tenga en cuenta que si se ejecuta NSSM de 32 bits en un sistema de 64 bits que ejecuta una versión anterior de Windows que Vista, no podrá consultar las rutas de los procesos de 64 bits.
NSSM puede volcar comandos que recrearían la configuración de un servicio. La salida se puede pegar en un script por lotes para hacer una copia de seguridad del servicio o transferir a otra computadora.
nssm dump <servicename>
Debido a que la configuración del servicio puede contener caracteres que deben cotizarse o escaparse del símbolo del sistema, NSSM intenta producir una salida difícil de producir que funcione correctamente cuando se ejecute como un script, agregando citas y escapes de careto según corresponda.
Para facilitar la copia de un servicio, el comando volcado acepta un segundo argumento que especifica el nombre del servicio que se utilizará en la salida.
nssm dump <servicename> <newname>
Las líneas en el volcado harán referencia al servicio al mostrar la configuración de.
Para instalar un servidor de torneo irreal:
nssm install UT2004 c:gamesut2004systemucc.exe server
Para ejecutar el servidor como usuario de "juegos":
nssm set UT2004 ObjectName games password
Para configurar el servidor para iniciar sesión en un archivo:
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.
