☰

為什麼我的 Systemd 單元已加載，但處於非活動狀態（死機）？

tag-icon • tag-icon systemd
為什麼我的 Systemd 單元已加載，但處於非活動狀態（死機）？

我正在嘗試設置石墨在我的伺服器上。我可以毫無問題地啟動 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/成功）”的單元？我以前見過失敗的單元，但是這個單元已成功加載但未運行，我不知道這意味著什麼。

答案1

根據 jasonwryan 的評論，雖然預設值Type=simple適用於許多 Systemd 服務文件，但當腳本啟動另一個進程並完成時，它不起作用ExecStart，就像石墨的 Carbon-cache.py 的情況一樣。在這些情況下，您需要Type=forking在[Service]部分中明確指定，以便 Systemd 知道查看生成的進程而不是初始進程。

如中所解釋的man systemd.service：

如果設定為 forking，則預期使用 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

相關內容