¿Por qué mi unidad Systemd está cargada, pero inactiva (muerta)?

Estoy tratando de configurar Graphite en mi servidor. Puedo iniciar el demonio Carbon Cache sin problemas sudo /opt/graphite/bin/carbon-cache.py start, pero estoy luchando para ejecutarlo como una unidad Systemd.

Esto es lo que tengo en mi archivo de servicio graphite.service:

[Unit]
Description=Carbon for Graphite

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

[Install]
WantedBy=multi-user.target

Pero cuando inicio la unidad obtengo el siguiente estado:

$ 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 no da más información.

¿Cómo debo interpretar y depurar unidades con un estado de "inactivo (muerto) ... (código = salido, estado = 0 / ÉXITO)"? He visto unidades fallidas antes, pero esta se ha cargado correctamente pero no se está ejecutando y no sé lo que eso significa.

Según el comentario de jasonwryan, aunque el valor predeterminado Type=simplefunciona para muchos archivos de servicio de Systemd, no funciona cuando el script ExecStartinicia otro proceso y se completa, como es el caso con carbon-cache.py de grafito. En estos casos, debe especificar explícitamente Type=forkingen la [Service]sección para que Systemd sepa mirar el proceso generado en lugar del inicial.

Como se explica en man systemd.service:

Si se establece en bifurcación, se espera que el proceso configurado con ExecStart = llame a fork () como parte de su inicio. Se espera que el proceso principal salga cuando se complete el inicio y se configuren todos los canales de comunicación. El niño continúa ejecutándose como el proceso principal del demonio. Este es el comportamiento de los demonios tradicionales de UNIX. Si se usa esta configuración, se recomienda usar también la opción PIDFile =, para que systemd pueda identificar el proceso principal del demonio. systemd procederá con el inicio de las unidades de seguimiento tan pronto como finalice el proceso principal.

Respuesta específica de grafito

Si bien lo anterior resolvió mi problema de Systemd, rápidamente me encontré con problemas específicos de grafito (con Twisted) y terminé volviendo a los valores predeterminados Type.

Grafito <0.9.12

En versiones anteriores de Graphite, solo se puede evitar la bifurcación utilizando la --debugopción:

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

Grafito> = 0.9.13

En esta solicitud de extracción--no-daemon , se fusionó una opción:

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