Pourquoi mon unité Systemd est-elle chargée, mais inactive (morte)?

J'essaie de configurer Graphite sur mon serveur. Je peux démarrer le démon Carbon Cache sans problème sudo /opt/graphite/bin/carbon-cache.py start, mais j'ai du mal à l'exécuter en tant qu'unité Systemd.

Voici ce que j'ai dans mon dossier de service graphite.service:

[Unit]
Description=Carbon for Graphite

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

[Install]
WantedBy=multi-user.target

Mais lorsque je démarre l'unité, j'obtiens le statut suivant:

$ 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 ne fournit plus d'informations.

Comment dois-je interpréter et déboguer les unités dont l'état est "inactif (mort) ... (code = quitté, état = 0 / SUCCÈS)"? J'ai déjà vu des unités en panne, mais celle-ci est chargée avec succès mais ne fonctionne pas et je ne sais pas ce que cela signifie.

Selon le commentaire de jasonwryan, bien que la valeur par défaut Type=simplefonctionne pour de nombreux fichiers de service Systemd, elle ne fonctionne pas lorsque le script dans ExecStartlance un autre processus et se termine, comme c'est le cas avec carbon-cache.py du graphite. Dans ces cas, vous devez spécifier explicitement Type=forkingdans la [Service]section afin que Systemd sache regarder le processus généré plutôt que le processus initial.

Comme expliqué dans man systemd.service:

S'il est défini sur forking, il est prévu que le processus configuré avec ExecStart = appelle fork () dans le cadre de son démarrage. Le processus parent devrait se terminer lorsque le démarrage est terminé et que tous les canaux de communication sont configurés. L'enfant continue de s'exécuter en tant que processus démon principal. C'est le comportement des démons UNIX traditionnels. Si ce paramètre est utilisé, il est recommandé d'utiliser également l'option PIDFile =, afin que systemd puisse identifier le processus principal du démon. systemd procédera au démarrage des unités de suivi dès la fin du processus parent.

Réponse spécifique au graphite

Alors que ce qui précède a résolu mon problème Systemd, j'ai rapidement rencontré des problèmes spécifiques au graphite (avec Twisted) et j'ai fini par revenir à la valeur par défaut Type.

Graphite <0.9.12

Dans les versions précédentes de Graphite, on ne peut éviter de bifurquer qu'en utilisant l' --debugoption:

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

Graphite> = 0.9.13

Dans cette demande de tirage, une --no-daemonoption a été fusionnée:

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