☰

Por que minha unidade Systemd está carregada, mas inativa (morta)?

tag-icon • tag-icon systemd
Por que minha unidade Systemd está carregada, mas inativa (morta)?

Estou tentando configurarGrafiteno meu servidor. Posso iniciar o daemon Carbon Cache sem problemas sudo /opt/graphite/bin/carbon-cache.py start, mas estou lutando para executá-lo como uma unidade Systemd.

Aqui está o que tenho em meu arquivo de serviço graphite.service:

[Unit]
Description=Carbon for Graphite

[Service]
ExecStart=/opt/graphite/bin/carbon-cache.py start

[Install]
WantedBy=multi-user.target

Mas quando inicio a unidade recebo o seguinte status:

$ systemctl status graphite.service            
* graphite.service - Carbon for Graphite
   Loaded: loaded (/etc/systemd/system/graphite.service; enabled)
   Active: inactive (dead) since Fri 2014-06-13 18:44:11 UTC; 2s ago
  Process: 4525 ExecStart=/opt/graphite/bin/carbon-cache.py start (code=exited, status=0/SUCCESS)
 Main PID: 4525 (code=exited, status=0/SUCCESS)

Jun 13 18:44:11 MEADOW systemd[1]: Started Carbon for Graphite.

Journalctl não produz mais informações.

Como devo interpretar e depurar unidades com status "inativo (morto)...(código=exited, status=0/SUCCESS)"?Já vi unidades com falha antes, mas esta foi carregada com sucesso, mas não está em execução e não sei o que isso significa.

Responder1

De acordo com o comentário de Jasonwryan, embora o padrão Type=simplefuncione para muitos arquivos de serviço do Systemd, ele não funciona quando o script ExecStartinicia outro processo e é concluído, como é o caso do carbon-cache.py do grafite. Nesses casos, você precisa especificar explicitamente Type=forkingna [Service]seção para que o Systemd saiba que deve observar o processo gerado em vez do inicial.

Conforme explicado em man systemd.service:

Se definido como forking, espera-se que o processo configurado com ExecStart= chame fork() como parte de sua inicialização. Espera-se que o processo pai seja encerrado quando a inicialização for concluída e todos os canais de comunicação estiverem configurados. O filho continua a ser executado como o processo daemon principal. Este é o comportamento dos daemons UNIX tradicionais. Caso esta configuração seja utilizada, é recomendado utilizar também a opção PIDFile=, para que o systemd possa identificar o processo principal do daemon. O systemd continuará iniciando as unidades de acompanhamento assim que o processo pai terminar.

Resposta específica de grafite

Embora o procedimento acima tenha resolvido meu problema com o Systemd, rapidamente me deparei com problemas específicos do grafite (com Twisted) e acabei voltando ao padrão Type.

Grafite <0,9.12

Nas versões anteriores do Graphite só era possível evitar a bifurcação usando a --debugopção:

[Service]
ExecStart=/opt/graphite/bin/carbon-cache.py --debug start

Grafite >= 0.9.13

Emesta solicitação pulluma --no-daemonopção foi mesclada:

[Service]
ExecStart=/opt/graphite/bin/carbon-cache.py --no-daemon start

informação relacionada