状態を気にしない「愚かな」システムユニットを作成する

状態を気にしない「愚かな」システムユニットを作成する

起動中に起動し、終了時に正常に終了するアプリケーションがあります。問題は、systemdを使用してアプリケーションを起動/停止できないことです。時には手動コマンドを使用して「部分的に」起動する必要がある非常に複雑なアプリケーションなので、systemdには実際に追跡するための良い方法はありません。アプリケーションの実際の状態。

そのため、サービスの状態に関係なく、起動時に特定のスクリプトを実行し、終了時に他のスクリプトを常に実行する「愚かな」システムデバイスが必要であるという結論に達しました。これが私が達成するのが難しいことです。テストに使用したものは次のとおりです。

[Unit]
Description=My Test application
Wants=network-online.target 
After=network-online.target

[Service]
Type=oneshot
ExecStart=/home/user/tmp/systemd-test/script.sh start
ExecStop=/home/user/tmp/systemd-test/script.sh stop
RemainAfterExit=true

[Install]
WantedBy=multi-user.target

上記の問題は、startが以前に実行されていない場合は「stop」を実行できず、その逆も同様です。

$ systemctl start test  # Start script is run
$ systemctl start test  # Nothing happens
$ systemctl stop test   # Stop script is run
$ systemctl stop test   # Nothing happens
$ systemctl stop test   # Nothing happens

したがって、起動中に何らかの理由で起動スクリプトが失敗し、アプリケーション管理者が手動で起動すると想像してください。その後、systemdに関する限り、正しく起動されなかったため、シャットダウン中に停止スクリプトは実行されません。

だから私の質問は、状態に気にしない「愚かな」システムサービスを作成する方法がありますか、それとも2つの異なる単位に分割する必要がありますか?

編集:期待どおりにsystemdが利用できない理由を詳しく説明するために、状態:アプリケーションを最初に起動するには、「サーバー」プロセスを開始する必要があります。実行すると、「ランチャー」プロセスが開始され、約20の異なるプロセスが開始されます。処理タイプは異なるプロセスを使用します。そしてすべてが非同期で始まります(つまり、非ブロック)。ログをgrepするか、カスタムバイナリを呼び出してプロセスを一覧表示する以外に、実際にいつ起動するのかを知る方法はありません。したがって、systemdでは、これら20のプロセスのうちの1つが起動に失敗したことを確認する方法はありません。

ベストアンサー1

だから私の質問は、状態に気にしない「愚かな」システムサービスを作成する方法があるかどうかということです。

あなたは試すことができますこれ(実行ファイルの前のダッシュに注意してください):

ExecStart=-/home/user/tmp/systemd-test/script.sh start

または

アプリケーションマネージャが入り、手動で起動します。

環境チェックなど、systemdを使用してスクリプトを具体的に実行させることができます。変える:

test -z "$INVOCATION_ID" && echo "This script must be run via systemd" && exit

おすすめ記事