为什么我的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没有更多信息。

我应该如何解释和调试状态为“无效（已死）...（代码=已退出，状态= 0 /成功）”的单元？我以前见过失败的单元，但是这个单元已经成功加载但没有运行，我不知道这意味着什么。

根据jasonwryan的评论，尽管默认设置Type=simple适用于许多Systemd服务文件，但是当脚本中的脚本ExecStart启动另一个进程并完成时，默认设置不起作用，就像石墨的carbon-cache.py一样。在这些情况下，您需要Type=forking在本[Service]节中明确指定，以便Systemd知道查看生成的进程，而不是初始进程。

如中所述man systemd.service：

如果设置为派生，则预期使用ExecStart =配置的进程将在其启动过程中调用fork（）。启动完成并设置所有通信通道后，预计父进程将退出。子级继续作为主守护进程运行。这是传统UNIX守护程序的行为。如果使用此设置，建议也使用PIDFile =选项，以便systemd可以识别守护程序的主进程。一旦父进程退出，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