☰

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

次のように説明されていますman systemd.service:

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

グラファイト特有の回答

上記で Systemd の問題は解決しましたが、すぐに graphite 固有の問題 (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

関連情報