起動時または再起動時にシェルスクリプトを呼び出すsystemdサービスを作成しました。
[Unit]
Description=Starts the DCCA index software
[Install]
WantedBy=multi-user.target
[Service]
ExecStart=/opt/insiteone/bin/indexControl start
ExecStop=/opt/insiteone/bin/indexControl stop
# Execute pre and post scripts as root
#PermissionsStartOnly=true
Restart=on-abort
TimeoutSec=600
最初は、それが開始されるとすぐに無限ループで再起動し続けましたが、TimeoutSecオプションを追加すると、サービスが初めて開始されるとすぐにExecStopが呼び出されました(開始され、すぐに再び停止しました)。
手がかり、どこが間違っているのですか? PS:indexControlは他のプロセスを開始するシェルスクリプトです
これがどの種類のデーモンであり、そこから何を期待できるかをsystemdに伝えていませんでした(最も重要なことは、デーモンがいつ起動したかを知る方法が必要です(== --- ==))。
デフォルトはType=simple
は、firstプロセスがメインサービスプロセスと見なされることを意味します。サービスが開始すると、サービス全体が「アクティブ(開始)」と見なされます。終了すると、サービス全体が停止します。
他の共通モードはType=forking
、最初のプロセスは少なくとも1回forkして終了することが期待され、「バックグラウンドで」または「デーモン化されて」実行されている子を残したままにします。
しかし、「whateverctl」ツールを使用している場合は、alwaysで必要な動作を確認できますType=forking
、それはツール自体がデーモンを「バックグラウンドで」開始し、終了しようとするためです。
上記と同様のSO答えは私にとってうまくいきませんでした。しかし この投稿 は最終的にはうまくいきました。
_[Unit]
Description=Setup foo
#After=network.target
[Service]
Type=oneshot
ExecStart=/opt/foo/setup-foo.sh
RemainAfterExit=true
ExecStop=/opt/foo/teardown-foo.sh
StandardOutput=journal
[Install]
WantedBy=multi-user.target
_
トリックは_RemainAfterExit=true
_ディレクティブでした。それは、私のスクリプトがsystemd
を見て自分自身の痕跡を残さなかったためです。したがって、次のsystemd
ステップは、常にExecStop
を呼び出して、「デーモンを残さないこの奇妙なスクリプト」を停止することでした。 Mootは本当です。
UPDATE 20180316:わかりました、ここ数か月のうちにsystemd
サービスについてすべてを忘れてしまったので、すべての作業を最初からやり直していました。幸いなことに、私は漠然とこの答えを思い出し、それを探して30分経過しました。そして今、私は再びここにいます。
今回再学習したことをいくつか追加しようと思います。systemd
スクリプトは_/etc/init
_に配置しないでください。これらのスクリプトはより目立たない_/etc/systemd/system
_ディレクトリにとどまる必要があります。 _.service
_ではなく_.conf
_と呼ばれます!
スクリプトが正しいディレクトリに置かれた後は、_Sudo systemctl daemon-reload
_が望ましいですが、_Sudo service [TAB]
_オートコンプリートリストにスクリプト名が表示されません。それにもかかわらず、新しいサービスは次の方法で起動できます。
_Sudo service myservice start
_
これで、サービスは記述された目的を実行します。確かに、呼び出されたスクリプトは機能しませんが、これは別の問題です。