NSSM
v2.25
O NSSM é um programa de auxiliar de serviço semelhante ao Srvany e CyGrunsrv. Ele pode iniciar qualquer aplicativo (como console) como um serviço NT e reiniciar o serviço se falhar por qualquer motivo.
O NSSM também possui um instalador de serviço gráfico e removedor.
Este é um garfo de NSSM
Arquivos binários que você pode encontrar nos lançamentos aqui
Código original: https://git.nssm.cc/nssm/nssm por Iain Patterson
Documentação: Uso, Comandos
Nas notas de uso abaixo, os argumentos para o programa podem ser escritos entre colchetes e/ou colchetes. significa que você deve inserir a string apropriada e [] significa que a string é opcional. Veja os exemplos abaixo ...
Observe que em todos os lugares aparece, você pode substituir o nome de exibição do serviço.
Para instalar um serviço, execute
nssm install <servicename>
Você será solicitado a inserir o caminho completo para o aplicativo que deseja executar e qualquer opção de linha de comando para passar para esse aplicativo.
Use o System Service Manager (Services.MSC) para controlar as propriedades avançadas de serviço, como o método de inicialização e a interação da área de trabalho. O NSSM pode suportar essas opções mais tarde ...
Para instalar um serviço, execute
nssm install <servicename> <application> [<options>]
O NSSM tentará instalar um serviço que execute o aplicativo nomeado com as opções fornecidas (se você especificou algum).
Não se esqueça de incluir caminhos em "citações" se elas contiverem espaços!
Se você deseja incluir citações nas opções que precisará "" "citação" "" as citações.
O NSSM iniciará o aplicativo listado no registro quando você o enviar um sinal de partida e será encerrado quando enviar um sinal de parada. Até agora, como Srvany. Mas o NSSM é o gerenciador de serviços que não suporta e pode agir se/quando o aplicativo morrer.
Sem configuração de você, o NSSM tentará se reiniciar se perceber que o aplicativo morreu, mas você não o enviou um sinal de parada. O NSSM continuará tentando, pausando entre cada tentativa, até que o serviço seja iniciado com sucesso ou você envie um sinal de parada.
O NSSM pausa um tempo cada vez mais longo entre as tentativas subsequentes de reinicialização se o serviço não começar em tempo hábil, até um máximo de quatro minutos. É assim que não consome uma quantidade excessiva de tempo da CPU tentando iniciar um aplicativo com falha repetidamente. Se você identificar a causa da falha e não quiser esperar, poderá usar o console de serviço do Windows (onde o serviço será mostrado no estado pausado) para enviar um sinal de continuação para o NSSM e ele tentará novamente em alguns segundos.
Por padrão, o NSSM define "uma maneira oportuna" a estar dentro de 1500 milissegundos. Você pode alterar o limite para o serviço definindo o número de milissegundos como um valor reg_dword no registro em hklm system currentControlset Services <Vower> Parameters Appthrottle.
Como alternativa, o NSSM pode pausar por uma quantidade configurável de tempo antes de tentar reiniciar o aplicativo, mesmo que ele tenha executado com sucesso a quantidade de tempo especificado pelo Appthrottle. O NSSM consultará o valor reg_dword em HKLM System CurrentControlSet Services <Vooms> Parameters AprotestartDelay para que o número de milissegundos aguardasse antes de tentar reiniciar. Se o AprotestartDelay estiver definido e o aplicativo estiver determinado a estar sujeito a limitação, o NSSM pausa o serviço para o que for mais longo do atraso de reinicialização configurado e o período do acelerador calculado.
Se o AprotestartDelay estiver ausente ou inválido, apenas a aceleração será aplicada.
O NSSM procurará no Registro em HKLM System CurrentControlset Services <Vower> Parameters AppExit para String (reg_expand_sz) valores correspondentes ao código de saída do aplicativo. Se o aplicativo saiu do Código 1, por exemplo, o NSSM procurará um valor de string no AppExit chamado "1" ou, se não o encontrar, voltará ao valor do AppExit (padrão). Você pode descobrir o código de saída para o aplicativo consultando o log de eventos do sistema. O NSSM registrará o código de saída quando o aplicativo sair.
Com base nos dados encontrados no registro, o NSSM tomará uma das três ações:
Se os dados do valor forem "reiniciar" o NSSM tentará reiniciar o aplicativo, conforme descrito acima. Este é o seu comportamento padrão.
Se os dados do valor forem "ignorar" o NSSM não tentará reiniciar o aplicativo, mas continuará sendo executado. Isso emula o comportamento (geralmente indesejável) da Srvany. O console do Windows Services mostraria o serviço como ainda em execução, mesmo que o aplicativo tenha saído.
Se os dados do valor forem "saída" o NSSM, sairá graciosamente. O console do Windows Services mostraria o serviço como parado. Se você deseja fornecer controle de granulação mais fino sobre a recuperação do serviço, use este código e edite a ação de falha manualmente. Observe que as versões do Windows antes do Vista não considerarão essa saída uma falha. Em versões mais antigas do Windows, você deve usar "suicídio".
Se os dados do valor forem "suicídio" o NSSM simulará uma falha e saída sem informar o gerente de serviço. Esta opção deve ser usada apenas para sistemas pré-vista, onde você deseja aplicar uma ação de recuperação de serviço. Observe que, se o aplicativo monitorado sair com o código 0, o NSSM honrará apenas uma solicitação de suicídio se você configurar explicitamente uma chave de registro para o código de saída 0. Se apenas a ação padrão estiver definida como suicídio NSSM, em vez disso, sairá graciosamente.
O NSSM pode definir a classe prioritária do aplicativo gerenciado. O NSSM procurará no Registro em HKLM System CurrentControlSet Services <Vower> Parameters para o AppPrimority de entrada reg_dword. Os valores válidos correspondem a argumentos para setPriorityClass (). Se AppPriority () estiver ausente ou inválido, o aplicativo será iniciado com prioridade normal.
O NSSM pode definir a afinidade da CPU do aplicativo gerenciado. O NSSM procurará no registro em HKLM System CurrentControlSet Services <Vooms> Parâmetros para a apropfinity de entrada reg_sz. Ele deve especificar um listado se separado por vírgula de IDs de processador indexados por zero. Uma gama de processadores pode opcionalmente ser especificada com um traço. Nenhum outro personagem é permitido na string.
Por exemplo, para especificar o primeiro; segundo; Terceiro e quinto CPUs, uma apurafinity apropriada seria 0-2,4.
Se o appafinity estiver ausente ou inválido, o NSSM não tentará restringir o aplicativo a CPUs específicas.
Observe que a versão de 64 bits do NSSM pode configurar um máximo de 64 CPUs dessa maneira e que a versão de 32 bits pode configurar um maxium de 32 CPUs, mesmo quando é executado em janelas de 64 bits.
Ao interromper um serviço, o NSSM tentará vários métodos diferentes para matar o aplicativo monitorado, cada um dos quais pode ser desativado, se necessário.
O primeiro NSSM tentará gerar um evento Control-C e enviá-lo para o console do aplicativo. Scripts em lote ou aplicativos de console podem interceptar o evento e se fechar graciosamente. Os aplicativos da GUI não possuem consoles e não responderão a esse método.
Em segundo lugar, o NSSM enumerará todas as janelas criadas pelo aplicativo e enviará uma mensagem WM_CLOSE, solicitando uma saída graciosa.
Em terceiro lugar, o NSSM enumerará todos os threads criados pelo aplicativo e enviará uma mensagem WM_QUIT, solicitando uma saída graciosa. Nem todos os threads dos aplicativos têm filas de mensagens; Aqueles que não não responderão a esse método.
Finalmente, o NSSM ligará para o términingProcess () para solicitar que o sistema operacional encerre o aplicativo à força. TermineProcess () não pode ser preso ou ignorado; portanto, na maioria das circunstâncias, o aplicativo será morto. No entanto, não há garantia de que ele terá a chance de executar quaisquer operações de Tidyup antes de sair.
Qualquer ou todos os métodos acima podem ser desativados. O NSSM procurará o HKLM System CurrentControlSet Services <Vooms> Parameters AppStopMethodsKip Valor do registro que deve ser do tipo Reg_Dword definido como um campo de bits descrevendo quais métodos não devem ser aplicados.
Se o AppStopMethodSkip incluir 1, os eventos do Control-C não serão gerados. Se o AppStopMethodskip incluir 2, as mensagens WM_CLOSE não serão publicadas. Se o AppStopMethodskip incluir 4, as mensagens wm_quit não serão publicadas. Se o AppStopMethodSkip incluir 8, o TerminEprocess () não será chamado.
Se, por exemplo, você soubesse que um aplicativo não respondeu aos eventos do Control-C e não tivesse uma fila de mensagens de thread, você poderia definir o AppStopMethodsKip como 5 e o NSSM não tentaria usar esses métodos para interromper o aplicativo.
Tome muito cuidado ao incluir 8 no valor do AppStopMethodSkip. Se o NSSM não ligar para o terminEprocess (), é possível que o aplicativo não saia quando o serviço parar.
Por padrão, o NSSM permitirá que os processos 1500ms respondam a cada um dos métodos descritos acima antes de prosseguir para o próximo. O tempo limite pode ser configurado por método, criando entradas de reg_dword no registro em HKLM System CurrentControlSet Services <Vooms> Parameters.
AppStopMethodConsole AppStopMethodWindow AppStopMethodThreads
Cada valor deve ser definido como o número de milissegundos para esperar. Observe que o tempo limite se aplica a cada processo na árvore de processos do aplicativo; portanto, o tempo real para desligar pode ser maior que a soma de todos os tempos de tempo configurados se o aplicativo gerar vários subprocessos.
Para pular a aplicação dos métodos de parada acima em todos os processos na árvore de processos do aplicativo, aplicando -os apenas ao processo de aplicação original, defina o HKLM System CurrentControlSet Services <Vower> Parameters AppkillProcessTree Registry Value, que deve ser do tipo Reg_Dword, para 0.
Por padrão, o NSSM criará uma janela de console para que os aplicativos capazes de ler a entrada do usuário possam fazê -lo - sujeito ao serviço que está sendo autorizado a interagir com a área de trabalho.
A criação do console pode ser suprimida definindo o número inteiro (reg_dword) hklm system currentControlset Services <Vooms> Parameters AppnocOnsole Registry Valor para 1.
O NSSM pode redirecionar a E/S do aplicativo gerenciado para qualquer caminho capaz de ser aberto pelo createfile (). Isso permite, por exemplo, capturar a saída de log de um aplicativo que, de outra forma, gravaria apenas no console ou aceitar a entrada de uma porta serial.
O NSSM procurará no registro em HKLM System CurrentControlSet Services <Vooms> parâmetros para as chaves correspondentes aos argumentos para createfile (). Todos são opcionais. Se nenhum caminho for fornecido para um fluxo específico, ele não será redirecionado. Se um caminho for fornecido, mas algum dos outros valores for omitido, eles receberão padrões sensatos.
Appstdin: caminho para receber entrada. Appstdout: caminho para receber saída. Appstderr: caminho para receber saída de erro.
Os parâmetros para createfile () estão fornecendo os valores "AppStDinsharemode", "AppStDincreationDisposition" e "Appstdinflagsandattributes" (e analogamente para stdout e stderr).
Em geral, se você deseja que o Serviço registre sua saída, defina AppStdout e AppStderr no mesmo caminho, por exemplo, usuários public Service.log, e deve funcionar. Lembre -se, no entanto, que o caminho deve estar acessível ao usuário executando o serviço.
Ao usar o redirecionamento de E/S, o NSSM pode girar os arquivos de saída existentes antes da abertura do STDOUT e/ou STDERR. Um arquivo existente será renomeado com um sufixo com base no último horário de gravação do arquivo, até a precisão de milissegundos. Por exemplo, o arquivo nssm.log pode ser girado para NSSM-20131221T113939.457.log.
O NSSM procurará no Registro em HKLM System CurrentControlset Services <Vower> Parâmetros para entradas reg_dword que controlam como a rotação acontece.
Se o aprotatefiles estiver ausente ou definido como 0, a rotação será desativada. Qualquer valor diferente de zero permite a rotação.
Se o aprotear os segundos não forem zero, um arquivo não será girado se o seu último tempo de gravação for menor que o número de segundos no passado.
Se o aprotateBytes for diferente de zero, um arquivo não será girado se for menor que o número fornecido de bytes. Os tamanhos dos arquivos de 64 bits podem ser tratados definindo um valor diferente de zero do aprotatebyteshigh.
Se o AprotatedAlay for diferente de zero, o NSSM fará uma pausa para o número fornecido de milissegundos após a rotação.
Se o AppStDoutCopyAndtruncate ou AppStderRCopyAndtruncate forem muito zero, o arquivo stdout (ou stderr, respectivamente) será girado pela primeira vez pegando uma cópia do arquivo, truncando o arquivo original para o tamanho zero. Isso permite que o NSSM gire os arquivos que são mantidos abertos por outros processos, impedindo que o MOVELFILE () usual tenha sucesso. Observe que o processo de cópia pode levar algum tempo se o arquivo for grande e consumir temporariamente o dobro do espaço em disco do que o arquivo original. Observe também que os aplicativos que lêem o arquivo de log podem não perceber que o tamanho do arquivo foi alterado. Usar esta opção em conjunto com o AprotatedElay pode ajudar nesse caso.
A rotação é independente dos parâmetros createfile () usados para abrir os arquivos. Eles serão girados independentemente de o NSSM os anexaria ou substituiu.
O NSSM também pode girar arquivos que atingem o limite de tamanho configurado enquanto o serviço está em execução. Além disso, você pode desencadear uma rotação sob demanda executando o comando
nssm rotate <servicename>
As rotações sob demanda acontecerão após a próxima linha de dados for lida no aplicativo gerenciado, independentemente do valor dos aproteitos. Esteja ciente de que, se o aplicativo não estiver particularmente detalhado, a rotação pode não acontecer há algum tempo.
Para ativar a rotação on-line e sob demanda, defina aprotateOnline como um valor diferente de zero.
Observe que a rotação on -line exige que o NSSM intercepte a E/S do aplicativo e crie os arquivos de saída em seu nome. Isso é mais complexo e propenso a erros do que simplesmente redirecionar os fluxos de E/S antes de iniciar o aplicativo. Portanto, a rotação on -line não está ativada por padrão.
Ao redirecionar a saída, o NSSM pode prefixar cada linha de saída com um registro de data e hora de precisão milissegunda, por exemplo:
2016-09-06 10:17:09.451 Pipeline main started
Para ativar a prefixação do registro de data e hora, defina o AppTimeStamPlog como um valor diferente de zero.
O prefixo se aplica ao stdout e ao Stderr. A prefixação requer interceptar a E/S do aplicativo da mesma maneira que a rotação on -line. Se a rotação do log e o prefixo do registro de data e hora estiverem ativados, a rotação estará online.
O NSSM pode substituir ou anexar ao ambiente do aplicativo gerenciado. Duas string com vários valores (reg_multi_sz) valores de registro são reconhecidas em HKLM System CurrentControlSet Services <Vooms> Parameters.
O Apfeganingment define uma lista de variáveis de ambiente que substituirão o ambiente do serviço. O ApaceRironmentExtra define uma lista de variáveis de ambiente que serão adicionadas ao ambiente do serviço.
Cada entrada na lista deve ser da chave do formulário = valor. É possível omitir o valor, mas o = símbolo é obrigatório.
As variáveis de ambiente listadas tanto no Apfeganingment quanto no ApnestivalmentExtra estão sujeitas a expansão normal; portanto, é possível, por exemplo, atualizar o caminho do sistema definindo "caminho = C: bin;%PATH%" no ApaceRiRonmentExtra. As variáveis são expandidas na ordem em que aparecem; portanto, se você deseja incluir o valor de uma variável em outra variável, você deve declarar a dependência primeiro.
Como as variáveis definidas no anexo substituem o ambiente existente, não é possível se referir a quaisquer variáveis que foram definidas anteriormente.
Por exemplo, o seguinte bloco de Appencenment:
PATH=C:WindowsSystem32;C:Windows
PATH=C:bin;%PATH%
Resultaria em um caminho de "c: bin; c: windows system32; c: windows" como esperado.
Enquanto o seguinte bloco de Appenevirment:
PATH=C:bin;%PATH%
Resultaria em um caminho que contém apenas C: bin e provavelmente faria com que o aplicativo não seja iniciado.
A maioria das pessoas vai querer usar exclusivamente o ApnevironmentExtra. A Srvany suporta apenas o Appenvironment.
A partir da versão 2.25, o NSSM analisa o Appenevirment e o ApnevironmentExtra, antes de ler quaisquer outros valores do registro. Como resultado, agora é possível consultar variáveis de ambiente personalizado em aplicativos, AppDirectory e outros parâmetros.
Todos os serviços do Windows podem ser passados variáveis de ambiente adicionais, criando uma sequência de vários valores (reg_multi_sz), denominada HLKM System CurrentControlset Services <Vower> Environment.
O conteúdo deste bloco de ambiente será mesclado no ambiente do sistema antes do início do serviço.
Observe, no entanto, que o ambiente mesclado será classificado em ordem alfabética antes de ser processada. Isso significa que, na prática, você não pode definir, por exemplo, Dir =%ProgramFiles%no Bloco Ambiental, porque o ambiente passado para o Serviço não terá definido%de programas de programas%quando se trata de definir%dir%. As variáveis ambientais definidas no ApaceRonmentExtra não sofrem com essa limitação.
A partir da versão 2.25, o NSSM pode obter e definir o bloco de ambiente usando comandos semelhantes a:
nssm get <servicename> Environment
Vale a pena reiterar que o Bloco Ambiente está disponível para todos os serviços do Windows, não apenas os serviços NSSM.
O ambiente NSSM passa para o aplicativo depende de como vários valores do registro são configurados. O fluxo a seguir descreve como o ambiente é modificado.
Por padrão: o serviço herda o ambiente do sistema.
Se ambiente estiver definido: o conteúdo do ambiente for mesclado no ambiente.
Se parâmetros Appenvironment for definido: o serviço herda o ambiente especificado no Appenvironment.
Se parâmetros ApponvironmentExtra for definido: o conteúdo do AppenvironmentExtra for anexado ao ambiente.
Observe que o Apfegan Ambiente substitui o ambiente do sistema e o bloco de ambiente mesclado. Observe também que o ApponvironmentExtra é garantido para ser anexado ao ambiente de inicialização, se for definido.
O NSSM pode executar comandos configuráveis pelo usuário em resposta a eventos de aplicativo. Esses comandos são chamados de "ganchos" abaixo.
Todos os ganchos são opcionais. Quaisquer ganchos executados serão lançados com o ambiente configurado para o serviço. O NSSM colocará variáveis adicionais no ambiente que os ganchos podem consultar para aprender como e por que foram chamados.
Os ganchos são categorizados por evento e ação. Alguns ganchos são executados de maneira síncrona e outros são executados de forma assíncrona. Os ganchos prefixados com um *asterisco são executados de maneira síncrona. O NSSM aguardará a conclusão desses ganchos antes de continuar seu trabalho. Observe, no entanto, que todos os ganchos estão sujeitos a um prazo, após o qual serão mortos, independentemente de serem executados de forma assíncrona ou não.
Evento: Iniciar - acionado quando o serviço é solicitado para iniciar. *Ação: Pré - chamado antes do NSSM tentar iniciar o aplicativo. Ação: Post - chamado após o início do aplicativo com sucesso.
Evento: Stop - acionado quando o serviço é solicitado para parar. *Ação: Pré - chamado antes do NSSM tentar matar o aplicativo.
Evento: Exit - acionado quando o aplicativo sair. *Ação: Post - chamado após o NSSM limpar o aplicativo.
Evento: Gire - acionado quando a rotação do log on -line for solicitada. *Ação: pré - chamado antes do NSSM girar os logs. Ação: Post - chamado após o NSSM girar os logs.
Evento: Ação de Power: Alterar - Chamado quando o status de energia do sistema foi alterado. Ação: currículo - chamado quando o sistema é retomado do modo de espera.
Observe que não há gancho de parada/post. Isso ocorre porque a saída/postagem é chamada quando o aplicativo sai, independentemente de ter feito isso em resposta a uma solicitação de desligamento de serviço. O STOP/PRE é chamado apenas antes de uma tentativa graciosa de desligamento.
O NSSM define a variável de ambiente nssm_hook_version para um número positivo. Os ganchos podem verificar o valor do número para determinar quais outras variáveis de ambiente estão disponíveis para eles.
Se nssm_hook_version for 1 ou maior, essas variáveis serão fornecidas:
Nssm_exe - caminho para o próprio NSSM. NSSM_CONFIGURAÇÃO - Crie informações para o executável NSSM, por exemplo, depuração de 64 bits. Nssm_version - versão do executável NSSM. Nssm_build_date - Data de construção do NSSM. NSSM_PID - ID do processo do executável NSSM em execução. NSSM_DEADLINE - Número do prazo de milissegundos, após o que o NSSM matará o gancho se ainda estiver em execução. Nssm_service_name - nome do serviço controlado pelo NSSM. NSSM_SERVICE_DISPLAYNAME - Nome de exibição do serviço. NSSM_COMMAND_LINE - linha de comando usada para iniciar o aplicativo. Nssm_application_pid - ID do processo do processo de aplicação primário. Pode estar em branco se o processo não estiver em execução. NSSM_EVENT - Classe de eventos acionando o gancho. NSSM_ACTION - Ação de evento acionando o gancho. NSSM_TRIGGER - Controle de serviço acionando o gancho. Pode estar em branco se o gancho não for acionado por um controle de serviço, por exemplo, saída/post. NSSM_LAST_CONTROL - Último controle de serviço tratado pelo NSSM. NSSM_START_REQUEST_COUNT - Número de vezes que o aplicativo foi solicitado para iniciar. NSSM_START_COUNT - Número de vezes o aplicativo iniciado com sucesso. Nssm_throttle_count - Número de vezes que o aplicativo foi executado por menos do que o período do acelerador. Redefina para zero no início bem -sucedido ou quando o serviço é explicitamente sem mouse. NSSM_EXIT_COUNT - Número de vezes o aplicativo saiu. NSSM_EXITCODE - Código de saída do aplicativo. Pode estar em branco se o aplicativo ainda estiver em execução ou ainda não tiver começado. Nssm_runtime - número de milissegundos para os quais o executável do NSSM está em execução. Nssm_application_runtime - Número de milissegundos para os quais o aplicativo está em execução desde que foi iniciado pela última vez. Pode estar em branco se o aplicativo ainda não tiver sido iniciado.
As versões futuras do NSSM podem fornecer mais variáveis de ambiente; nesse caso, o NSSM_HOOK_VERSION será definido como um número maior.
Os ganchos são configurados criando valores de String (reg_expand_sz) no registro nomeado após a ação do gancho e colocados em HKLM System CurrentControlSet Services <Vower> Parameters Appevents <vent>.
Por exemplo, o serviço pode ser configurado para reiniciar quando o sistema retomar a partir de espera, configurando os appEvents Power retomar para:
%NSSM_EXE% restart %NSSM_SERVICE_NAME%
Para definir um gancho na linha de comando, use
nssm set <servicename> AppEvents <event>/<action> <command>
Observe que o NSSM abortará a inicialização do aplicativo se um gancho de início/pré -gancho retornar o código de saída de 99.
Um serviço normalmente executa ganchos na seguinte ordem:
Iniciar/pré -iniciar/parar/pré -sair/postar
Se o aplicativo travar e for reiniciado pelo NSSM, o pedido poderá ser:
Iniciar/pré -iniciar/sair/postar Iniciar/Pré Iniciar/Post Stop/Pré -Exit/Post
Se o NSSM estiver redirecionando o stdout ou o stderr, ele poderá ser configurado para redirecionar a saída de qualquer gancho que execute. Defina o AppSedirECThooks como 1 para ativar essa funcionalidade. É claro que um gancho pode redirecionar sua própria E/S independentemente do NSSM.
O NSSM pode editar as configurações dos serviços existentes com a mesma GUI usada para instalá -los. Correr
nssm edit <servicename>
Para trazer à tona a GUI.
O NSSM oferece recursos de edição limitados para serviços que não sejam aqueles que executam o próprio NSSM. Quando o NSSM é solicitado a editar um serviço que não possui as configurações de registro do aplicativo descritas acima, a GUI permitirá a edição apenas configurações do sistema, como o nome e a descrição do Exibir de Serviço.
O NSSM pode recuperar ou definir parâmetros de serviço individuais na linha de comando. Em geral, a sintaxe é a seguinte, embora veja abaixo as exceções.
nssm get <servicename> <parameter>
nssm set <servicename> <parameter> <value>
Os parâmetros também podem ser redefinidos para seus valores padrão.
nssm reset <servicename> <parameter>
Os nomes dos parâmetros reconhecidos pelo NSSM são os mesmos dos nomes de entrada do registro descritos acima, por exemplo, AppDirectory.
O NSSM oferece recursos de edição limitados para serviços que não sejam aqueles que executam o próprio NSSM. Os parâmetros reconhecidos são os seguintes:
Descrição: Descrição do serviço. DisplayName: Nome de exibição de serviço. Meio Ambiente: Ambiente Mesclado por Serviço. ImagePath: caminho para o serviço executável. ObjectName: conta de usuário que executa o serviço. Nome: Nome da chave do serviço. Iniciar: Tipo de inicialização de serviço. Tipo: Tipo de serviço.
Eles correspondem aos valores do registro sob a chave HKLM System CurrentControlset do Serviço Serviços <Vooms>.
Observe que o NSSM concatenará todos os argumentos passados na linha de comando com espaços para formar o valor a ser definido. Assim, as duas invocações a seguir teriam o mesmo efeito.
nssm set <servicename> Description "NSSM managed service"
nssm set <servicename> Description NSSM managed service
Os parâmetros de Appenvironment, ApnevironmentExtra e Ambiente reconhecem um argumento adicional ao consultar o ambiente. A sintaxe seguinte imprimirá todas as variáveis de ambiente extras configuradas para um serviço
nssm get <servicename> AppEnvironmentExtra
Enquanto a sintaxe abaixo imprimirá apenas o valor da variável de patê de classe se estiver configurada no bloco de ambiente ou na sequência vazia, se não estiver configurada.
nssm get <servicename> AppEnvironmentExtra CLASSPATH
Ao definir um bloco de ambiente, cada variável deve ser especificada como um par de key = value em argumentos de linha de comando separados. Por exemplo:
nssm set <servicename> AppEnvironment CLASSPATH=C:Classes TEMP=C:Temp
Como alternativa, a chave pode ser prefixada com símbolo A + ou - para adicionar ou remover respectivamente um par do bloco.
As duas linhas a seguir definem o ClassPath and Temp:
nssm set <servicename> AppEnvironment CLASSPATH=C:Classes
nssm set <servicename> AppEnvironment +TEMP=C:Temp
Se a chave já estiver presente, especificar +a chave substituirá o valor ao preservar a ordem das chaves:
nssm set <servicename> AppEnvironment +CLASSPATH=C:NewClasses
A sintaxe a seguir remove uma única variável do bloco, deixando outras variáveis no local.
nssm set <servicename> AppEnvironment -TEMP
Especificar -Key = Value removerá a variável somente se o valor existente corresponder.
A sintaxe a seguir não removeria temp = c: temp
nssm set <servicename> AppEnvironment -TEMP=C:WorkTemporary
Os símbolos + e - são caracteres válidos em variáveis de ambiente. A sintaxe: key = valor é equivalente a key = value e pode ser usada para definir variáveis que começam com +/- ou para redefinir explicitamente o bloco em um script:
nssm set <servicename> AppEnvironment :CLASSPATH=C:Classes
nssm set <servicename> AppEnvironment +TEMP=C:Temp
O parâmetro AppExit requer um argumento adicional especificando o código de saída para obter ou definir. A ação padrão pode ser especificada com o padrão da string.
Por exemplo, para obter a ação de saída padrão para um serviço que você deve executar
nssm get <servicename> AppExit Default
Para obter a ação de saída quando o aplicativo sair do código de saída 2, execute
nssm get <servicename> AppExit 2
Observe que, se nenhuma ação explícita estiver configurada para um código de saída especificado, o NSSM imprimirá a ação de saída padrão.
Para configurar o serviço para parar quando o aplicativo sair com um código de saída de 2, execute
nssm set <servicename> AppExit 2 Exit
O parâmetro AppPriority é usado para definir a classe prioritária do aplicativo gerenciado. As prioridades válidas são as seguintes:
Realtime_priority_class high_priority_class acima_normal_priority_class normal_priority_class abaixo_normal_priority_class IDLE_PRIORITY_CLASS
Os parâmetros DependenGroup e Dependnservice são usados para consultar ou definir as dependências para o serviço. Ao definir dependências, cada grupo de serviço ou serviço (precedido com o símbolo +) deve ser especificado em argumentos de linha de comando separados. Por exemplo:
nssm set <servicename> DependOnService RpcSs LanmanWorkstation
Como alternativa, o nome da dependência pode ser prefixado com símbolo A + ou - para adicionar ou remover respectivamente uma dependência.
As duas linhas a seguir definem dependências em RPCSs e LanmanworkStation:
nssm set <servicename> DependOnService RpcSs
nssm set <servicename> DependOnService +LanmanWorkstation
A sintaxe Follwing remove a dependência de RPCSs:
nssm set <servicename> DependOnService -RpcSs
Os grupos de serviços devem, estritamente falando, ser prefixados com o símbolo +. Para especificar uma única dependência de um grupo, o símbolo + pode ser prefixado com o: símbolo.
As linhas a seguir são equivalentes e cada uma dependente apenas no NetBiOSGroup:
nssm set <servicename> DependOnGroup NetBIOSGroup
nssm set <servicename> DependOnGroup :NetBIOSGroup
nssm set <servicename> DependOnGroup :+NetBIOSGroup
Enquanto essas linhas adicionam a quaisquer dependências existentes:
nssm set <servicename> DependOnGroup +NetBIOSGroup
nssm set <servicename> DependOnGroup ++NetBIOSGroup
O parâmetro de nome só pode ser consultado, não definido. Ele retorna o nome de chave do registro do serviço. Isso pode ser útil saber se você aproveitar o fato de poder substituir o nome de exibição do serviço em qualquer lugar onde a sintaxe exige.
O parâmetro ObjectName requer um argumento adicional somente ao definir um nome de usuário. O argumento adicional é a senha do usuário.
Para recuperar o nome de usuário, corra
nssm get <servicename> ObjectName
Para definir o nome de usuário e a senha, execute
nssm set <servicename> ObjectName <username> <password>
Observe que as regras de concatenação de argumentos ainda se aplicam. A invocação a seguir é válida e terá o efeito esperado.
nssm set <servicename> ObjectName <username> correct horse battery staple
Os seguintes nomes de usuário bem conhecidos não precisam de uma senha. O parâmetro de senha pode ser omitido ao usá -los:
"Sistema" Aka "System" Aka "Aka" NT Authority System "" AKA "AKA" AKA "AKA" AKA "NT AUTORIDADE Serviço local" "NetworkService" AKA "Serviço de rede" Aka "NT Autoridade Serviço de Rede" Conta de Serviço Virtual "NT Service <Verticename>"
O parâmetro inicial é usado para consultar ou definir o tipo de inicialização do serviço. Os tipos de inicialização de serviços válidos são os seguintes:
Service_auto_start: inicialização automática na inicialização. Service_Delayed_Start: Startup atrasado na inicialização. Service_Demand_Start: Startup de serviço manual. Service_disabled: O serviço está desativado.
Observe que o serviço_delayed_start não é suportado nas versões do Windows antes do Vista. O NSSM definirá o serviço para inicialização automática se o início atrasado não estiver disponível.
O parâmetro de tipo é usado para consultar ou definir o tipo de serviço. O NSSM reconhece todos os tipos de serviço atualmente documentados, mas permitirá apenas definir um dos dois tipos:
Service_win32_own_process: um serviço independente. Este é o padrão. Service_Interactive_Process: um serviço que pode interagir com a área de trabalho.
Observe que um serviço só pode ser configurado como interativo se executar na conta do sistema local. A maneira segura de configurar um serviço interativo está em dois estágios da seguinte forma.
nssm reset <servicename> ObjectName
nssm set <servicename> Type SERVICE_INTERACTIVE_PROCESS
O NSSM oferece recursos de controle de serviço rudimentares.
nssm start <servicename>
nssm restart <servicename>
nssm stop <servicename>
nssm status <servicename>
nssm statuscode <servicename>
A saída do "status NSSM" e "NSSM StatusCode" é uma sequência que representa o estado de serviço, por exemplo, serviços_running.
O código de saída do "status do NSSM" será 0 se o status foi recuperado com sucesso. Se o código de saída não for zero, houve um erro.
O código de saída do "NSSM StatusCode" será o valor numérico do estado de serviço, por exemplo, para serviço_running. Zero não é um código de estado de serviço válido. Se o código de saída for zero, houve um erro.
O NSSM também pode remover serviços. Correr
nssm remove <servicename>
Para remover um serviço. Você solicitará a confirmação antes que o serviço seja removido. Tente não remover os serviços essenciais do sistema ...
Para remover um serviço sem confirmação da GUI, execute
nssm remove <servicename> confirm
Tente não remover os serviços essenciais do sistema ...
NSSM logs no log de eventos do Windows. Ele se registra como uma fonte de log de eventos e usa IDs de eventos exclusivos para cada tipo de mensagem que ele logs. Novas versões podem adicionar tipos de eventos, mas os IDs de eventos existentes nunca serão alterados.
Devido à maneira como o NSSM se registra, você deve estar ciente de que talvez não consiga substituir o binário do NSSM se o visualizador de eventos abre e que executando várias instâncias do NSSM de diferentes locais podem ser confusas se não forem todas as mesmas versão.
O comando a seguir imprimirá os nomes de todos os serviços gerenciados pelo NSSM:
nssm list
Para ver todos os serviços no sistema, não apenas o NSSM, use a lista tudo:
nssm list all
O comando a seguir imprimirá o ID do processo e o caminho executável dos processos iniciados por um determinado serviço:
nssm processes <servicename>
Observe que se o NSSM de 32 bits for executado em um sistema de 64 bits executando uma versão mais antiga do Windows que o Vista, não poderá consultar os caminhos de processos de 64 bits.
O NSSM pode despejar comandos que recriassem a configuração de um serviço. A saída pode ser colada em um script em lote para fazer backup do serviço ou transferir para outro computador.
nssm dump <servicename>
Como a configuração do serviço pode conter caracteres que precisam ser citados ou escapados do prompt de comando, o NSSM tenta produzir a saída que funcionará corretamente quando executado como um script, adicionando cotações e escapadas, conforme apropriado.
Para facilitar a cópia de um serviço, o comando dump aceita um segundo argumento que especifica o nome do serviço a ser usado na saída.
nssm dump <servicename> <newname>
As linhas no despejo farão referência ao serviço ao mostrar a configuração de.
Para instalar um servidor de torneio Unreal:
nssm install UT2004 c:gamesut2004systemucc.exe server
Para executar o servidor como o usuário "jogos":
nssm set UT2004 ObjectName games password
To configure the server to log to a file:
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.
