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

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

Aqui está o que eu tenho no 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.

O Journalctl não fornece mais informações.

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

Pelo 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 da grafite. Nesses casos, é necessário especificar explicitamente Type=forkingna [Service]seção, para que o Systemd saiba examinar o processo gerado, e não o processo inicial.

Como explicado em man systemd.service:

Se definido como bifurcação, espera-se que o processo configurado com ExecStart = chame fork () como parte de sua inicialização. Espera-se que o processo pai saia quando a inicialização estiver concluída e todos os canais de comunicação estiverem configurados. A criança continua sendo executada como o processo principal daemon. Esse é o comportamento dos daemons tradicionais do UNIX. Se essa configuração for usada, é recomendável usar também a opção PIDFile =, para que o systemd possa identificar o processo principal do daemon. O systemd continuará com as unidades de acompanhamento assim que o processo pai terminar.

Resposta específica de grafite

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

Grafite <0.9.12

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

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

Grafite> = 0.9.13

Em esta solicitação puxar a --no-daemonopção foi incorporada:

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