Systemdユニットがロードされているのに、非アクティブ（デッド）なのはなぜですか？

サーバーでGraphiteをセットアップしようとしています。Carbon Cacheデーモンはで問題なく起動できますsudo /opt/graphite/bin/carbon-cache.py startが、Systemdユニットとして実行するのに苦労しています。

サービスファイルにはgraphite.service次のものがあります。

[Unit]
Description=Carbon for Graphite

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

[Install]
WantedBy=multi-user.target

しかし、ユニットを起動すると、次のステータスになります。

$ 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はこれ以上情報を生成しません。

「非アクティブ（デッド）...（code = exited、status = 0 / SUCCESS）」のステータスのユニットをどのように解釈およびデバッグする必要がありますか？以前に故障したユニットを見たことがありますが、このユニットは正常にロードされていますが、実行されておらず、その意味がわかりません。

jasonwryanのコメントによると、デフォルトType=simpleは多くのSystemdサービスファイルで機能しますが、ExecStartグラファイトのcarbon-cache.pyの場合のように、スクリプトが別のプロセスを起動して完了すると機能しません。これらの場合、Systemdが最初のプロセスではなく、生成されたプロセスを見ることができるようType=forkingに、[Service]セクションで明示的に指定する必要があります。

で説明したようにman systemd.service：

forkに設定されている場合、ExecStart =で構成されたプロセスは、起動の一部としてfork（）を呼び出すことが予想されます。起動が完了し、すべての通信チャネルが設定されると、親プロセスは終了する予定です。子は引き続きメインデーモンプロセスとして実行されます。これは、従来のUNIXデーモンの動作です。この設定を使用する場合、systemdがデーモンのメインプロセスを識別できるように、PIDFile =オプションも使用することをお勧めします。systemdは、親プロセスが終了するとすぐにフォローアップユニットを開始します。

グラファイト固有の回答

上記は私のSystemdの問題を解決しましたが、すぐにグラファイト固有の問題（Twistedを使用）に遭遇し、デフォルトに戻りましたType。

グラファイト<0.9.12

Graphiteの以前のバージョンでは、次の--debugオプションを使用することによってのみ分岐を回避できます。

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

グラファイト> = 0.9.13

で、このプルリクエスト--no-daemonオプションがマージされました：

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