Início / unix / Perguntas / 442575
Accepted
Dave
Asked: 2018-05-09 07:24:41 +0800 CST

Como descubro por que meu serviço systemctl não foi iniciado no CentOS 7?

  • 772

Estou usando o CentOS 7. Como descubro por que um serviço está falhando ao iniciar? Eu criei este serviço

[rails@server ~]$ sudo cat /usr/lib/systemd/system/nodejs.service
[Unit]
Description=nodejs server

[Service]
User=rails
Group=rails
ExecStart=/home/rails/NodeJSserver/start.sh
ExecStop=/home/rails/NodeJSserver/stop.sh

[Install]
WantedBy=multi-user.target

O arquivo aponta para isso

[rails@server ~]$ cat /home/rails/NodeJSserver/start.sh
#!/bin/bash

forever start /home/rails/NodeJSserver/server.js

Eu posso executar este arquivo muito bem por si só. Mas quando tento executá-lo como parte do serviço, percebo que meu servidor nodeJS não foi iniciado. Mesmo quando verifico "sudo systemctl --state=failed", não vejo nenhum erro ...

[rails@server ~]$ sudo systemctl enable NodeJSserver
[rails@server ~]$ sudo systemctl start NodeJSserver
[rails@server ~]$
[rails@server ~]$
[rails@server ~]$ forever list
info:    No forever processes running
[rails@server ~]$
[rails@server ~]$
[rails@server ~]$ sudo systemctl --state=failed
  UNIT                           LOAD   ACTIVE SUB    DESCRIPTION
● nginx.service                  loaded failed failed The nginx HTTP and reverse proxy server
● systemd-sysctl.service         loaded failed failed Apply Kernel Variables
● systemd-vconsole-setup.service loaded failed failed Setup Virtual Console

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.

3 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.

Como descubro por que meu serviço falhou ao iniciar?

centos boot

1 respostas

  1. Best Answer

    Seu serviço não foi Type=especificado na [Service]seção, então systemdsuponha que você quis dizer Type=simple.

    Isso significa systemdque esperará que o processo iniciado ExecStart=continue em execução enquanto o serviço estiver em execução. Mas parece que você start.shexecuta apenas um comando e sai. Esse é o forevercomando : forever startinicia o comando de destino como um daemon, ou seja, em segundo plano. Assim que o forever startcomando for concluído, o shell em execução start.shserá encerrado.

    Nesse ponto, systemdconsidera este serviço como com falha. Mas espere, o grupo de controle atribuído a esse serviço ainda tem um processo em execução. "Então", pensa systemd, "não só falhou, mas também deixou uma bagunça depois de si. Não pode permitir isso." Como não há KillMode=nem KillSignal=especificado, systemdcontinua com seus padrões e envia um SIGTERM para quaisquer processos restantes naquele grupo de controle e, se eles não pararem em tempo hábil, segue com um SIGKILL. Depois disso, seu processo NodeJS real estará morto, garantido.

    Como corrigi-lo

    Como o comando com o qual você executa ExecStart=sairá assim que o servidor real for iniciado, você não poderá usar o padrão Type=simple. Você deve especificar outro tipo de serviço.

    Você poderia usar o Type=forking. Com esse tipo, man systemd.servicerecomenda o uso de uma PIDFile=opção, portanto, se o seu servidor NodeJS criar um arquivo PID para si mesmo (ou você adicionar opções ao forevercomando para que ele crie um para ele), informe systemdonde ele estará.

    [Service]
Type=forking
PIDFile=/absolute/path/to/nodejs.pid
User=rails
... <the rest as before>

    Se Type=forkingnão funcionar para você, você pode especificar Type=oneshotcom RemainAfterExit=yes.

    Isso faz com que systemdapenas execute o ExecStart=comando ao iniciar seu serviço e ExecStop=ao interrompê-lo, e não se preocupe com mais nada.

    systemdainda se lembrará se o serviço foi definido pela última vez em um estado parado ou iniciado. Portanto, se você definir outro serviço para depender desse serviço e interromper seu serviço NodeJS manualmente, o outro serviço não será interrompido automaticamente e, sem dúvida, retornará erros quando não puder usar seu serviço NodeJS.

    A terceira opção é pular forevertotalmente o comando e deixar systemdfazer o trabalho de reiniciar o processo NodeJS. Nesse caso, toda a sua nodejs.serviceunidade seria:

    [Unit]
Description=nodejs server

[Service]
User=rails
Group=rails
ExecStart=/home/rails/NodeJSserver/server.js
Restart=always

[Install]
WantedBy=multi-user.target

    Você pode adicionar outras opções.

    Por exemplo, você pode especificar RestartSec=5uma suspensão de 5 segundos antes de tentar reiniciar o serviço se ele morrer inesperadamente, para evitar sobrecarregar os recursos do sistema com tentativas frequentes de reinicialização se o serviço continuar morrendo imediatamente após ser reiniciado por algum motivo. (O RestartSec=valor padrão é 100 ms.)

    Ou se você deseja que o serviço seja reiniciado se retornar alguns valores de status de saída específicos, mas considera que falhou em outros, também existem opções para isso.

    • 23

relate perguntas