Por que o systemd está interrompendo o serviço imediatamente após ser iniciado?

5

Eu criei um serviço systemd que deve invocar um script de shell, quando iniciado ou na reinicialização.

[Unit]
Description=Starts the DCCA index software

[Install]
WantedBy=multi-user.target

[Service]
ExecStart=/opt/insiteone/bin/indexControl start
ExecStop=/opt/insiteone/bin/indexControl stop

# Execute pre and post scripts as root
#PermissionsStartOnly=true
Restart=on-abort
TimeoutSec=600

nitialmente ele continuou reiniciando em loop infinito assim que é iniciado, mas quando eu adicionei a opção TimeoutSec, ele chamou o ExecStop assim que o serviço foi iniciado pela primeira vez (iniciado e depois interrompido imediatamente) .

Qualquer pista, onde eu estou indo errado? P.S: indexControl é um script de shell, que inicia outros processos

    
por kingsmasher1 05.01.2016 / 17:06

2 respostas

4

Você não disse ao systemd que tipo de daemon é e o que esperar dele (o mais importante, é como saber quando o daemon finalmente foi iniciado ).

O padrão é Type=simple , o que significa que o processo primeiro é considerado o processo principal do serviço. No momento em que começa, todo o serviço é considerado "ativo (iniciado)"; no momento em que sai, todo o serviço é interrompido.

O outro modo comum é Type=forking , em que o processo inicial deve chegar pelo menos uma vez e sair, deixando um filho executando "em segundo plano" ou "daemonizado" como alguns chamam.

Mas se você está passando por uma ferramenta "whateverctl", você sempre vai ver o comportamento que precisa de Type=forking , já que a ferramenta em si tente iniciar o daemon "em segundo plano" e saia sozinho.

    
por 06.01.2016 / 07:45
2

Nenhuma das respostas SO acima e similares funcionou para mim. Mas este post acabou por fazer.

[Unit]
Description=Setup foo
#After=network.target

[Service]
Type=oneshot
ExecStart=/opt/foo/setup-foo.sh
RemainAfterExit=true
ExecStop=/opt/foo/teardown-foo.sh
StandardOutput=journal

[Install]
WantedBy=multi-user.target

Qual foi o truque da diretiva RemainAfterExit=true . Isso porque meu script não deixou nenhum traço de si mesmo para systemd , então a próxima systemd step foi sempre chamar ExecStop para parar "este script estranho que não deixa um daemon para trás". Moot mas verdadeiro.

UPDATE 20180316 : Ok, eu esqueci completamente tudo sobre systemd services nesses poucos meses, então eu estava refazendo todo o trabalho do zero. Felizmente me lembrei vagamente dessa resposta, passei meia hora procurando por ela e agora estou aqui de novo.

Vou tentar adicionar apenas algumas coisas que aprendi desta vez: systemd scripts não devem ser colocados em /etc/init , eles ficam no diretório mais hediondo /etc/systemd/system , e eles ' chamado novamente de .service , não .conf !

Depois que o script estiver no diretório correto, um sudo systemctl daemon-reload é desejável, mas o nome do script não aparecerá na lista sudo service [TAB] autocomplete. No entanto, o novo serviço pode ser lançado com:

sudo service myservice start

E é isso, agora o serviço está fazendo o que foi escrito. Com certeza o script chamado não, mas esse é outro problema.

    
por 11.08.2017 / 18:03

Tags