☰

systemd が予期しない終了を失敗として扱うようにします。

tag-icon • tag-icon signals exit-status systemd-unit
systemd が予期しない終了を失敗として扱うようにします。

システムサービスユニットにサードパーティの実行可能ファイルをラップして管理します。私はこのプログラムの動作を変えることができず、その終了コードも信頼しません。終了コード 0 や外部 SIGTERM を含む systemd によって発生しなかった終了を失敗として扱い、systemd のインタフェースを介して違いを検出できるようにしたいと思います。

現在私のデバイスは次のとおりです。

[Unit]
Description=Foo service
Requires=bar.service
After=bar.service

[Service]
ExecStart=/opt/foo/foo -stayresident
KillMode=control-group
Restart=no

サービスプロセスを手動で終了すると、ステータスを確認すると「非アクティブ」状態になります。systemctl

killall foo && systemctl status foo.service

killにアップグレードすると-9「失敗」が発生します。

killall -9 foo && systemctl status foo.service

これは私が拡張したい行動です。

わかりましたSuccessExitStatus=サービス単位の設定では、ゼロ以外の終了およびその他の障害タイプを成功として計算できますが、その逆は表示されません。

ベストアンサー1

おそらく必要なものを理解していないかもしれませんが、fooコマンドの後に失敗したコマンドを追加するなどの簡単な操作を実行できます。 2番目のコマンドはによって実行されませんsystemctl stop。たとえば、次のようExecStartに置き換えます。

ExecStart=/bin/bash -c '/opt/foo/foo -stayresident && exit 7'

7は、状態でより明確に見えるように選択されています。シグナルによって終了するか、それfoo自体で終了すると、シェルプロセスは引き続き実行され、終了コード7とシステム状態になります。失敗。完了すると、systemctl stopシェルは状態で終了します。非アクティブ（死）。自然に放出されたすべての障害信号は、exit 7元のコマンドが成功した場合にのみfoo保持することができます。

コマンドkillall fooの一致を防ぐには、次のトリックを使用できます。bashbash -c '/opt/"f"oo/"f"oo ...'

おすすめ記事