Systemdは、失敗したサービスの再起動を遅らせ、30の省電力時間を追加するようです。

Question

あなたのサービスにType=forking。サービスの実行中に存在します。完了すると、生成されたプロセス（）が選択され、この状態に入ります。ExecStart=fork()activating (start)ExecStart=ExecStart=systemdMainPIDactive (running)

あなたのExecStart=プログラムはbashスクリプトのようです。スクリプトは次のとおりです。

#!/bin/bash
sudo -u admin -i python /path/to/application/myapplication.py start p1 | logger &

while /bin/true; do
    sleep 30
done

スクリプトにはいくつかの問題がありますが、興味があるのはsleep 30最後の部分です。基本プロセスは実行中ですが、systemdはactive (running)完了するまでその状態に入りませんsleep 30。新しいPIDがsleep 30引き続き呼び出されるので、毎回新しいPIDが表示されます。

うまく動作するスクリプトは、アプリケーションを作成した直後に終了します。スクリプトは、アプリケーションが終了する前に正しく開始されたというフィードバックを待っている可能性があります。これは問題ありませんが、待っているフィードバックが確実に得られていないため、そうでない理由を理解するためにもっと深く掘り下げる必要があります。

しかし、私の考えでは、スクリプトがアプリケーションが終了する前に終了するのを待っている可能性が高くなります。このような：

python myapplication.py &
PID=$!

while ps | grep -q $PID; do
    sleep 30
done

台本ではなく、あなたがやっているkillように聞こえるからだと思います。これは、デバイスが完了するまでそのまま残ります。次に、スクリプトが停止する前に、PythonアプリケーションのPIDがまだ存在する（存在しない）ことを確認してください。pythonExecStart=activating (start)sleep 30

私を悩ませるもう一つのスクリプトの部分は、対話型ユーザーを認証するsudoこと sudoです。スクリプトを検証するためのものではありません。代わりに、よりエレガントな解決策はUser=adminサービス内でそれを使用することです。

2つの解決策があります。オプション2は私が一番好きなものです。

ループを編集し/path/to/application/myapplicationて削除しますwhile。
簡単なサービスを使用してスクリプトを完全にスキップします。これは、他の初期化システム（現在は不要な独自のロガーを明示的に起動する）用に作成され、次にシェルから呼び出されたときにブロックされるように変更されたようです。 systemdこれはすべてあなたのために行われたので、スクリプトはまったく必要ありません。

[Unit]
Description=my application service for %i.

[Service]
Type=simple
ExecStart=/usr/bin/python3 /path/to/application/myapplication.py %i
User=admin
Restart=always

[Install]
WantedBy=multi-user.target

役に立たない場合は投稿してください。/path/to/application/myapplication

Answer 1