☰

Systemdデバイスがロードされたが非アクティブ（凍結）されたのはなぜですか？

tag-icon • tag-icon systemd
Systemdデバイスがロードされたが非アクティブ（凍結）されたのはなぜですか？

設定しようとしています。石黙私のサーバーに。問題なくCarbon Cacheデーモンを起動できますが、sudo /opt/graphite/bin/carbon-cache.py startSystemdデバイスとして実行できません。

マイサービスファイルの内容は次のとおりです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のコメントによると、デフォルトは多くのSystemdサービスファイルで機能しますが、GraphiteのCarbon-cache.pyの場合と同様に、Type=simpleスクリプトが他のプロセスを開始して完了すると機能しません。このような場合は、Systemdが最初のプロセスではなく作成されたプロセスを確認するようにセクションで明示的に指定するExecStart必要がありますType=forking。[Service]

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

ブランチに設定されている場合、ExecStart =で設定されたプロセスは開始の一部としてブランチ（）を呼び出す必要があります。起動が完了し、すべての通信チャネルが確立されると、親プロセスが終了すると予想されます。子プロセスは引き続きデフォルトデーモンとして実行されます。これは従来の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

関連情報