Linux Systemd-在ExecStopPost中检测服务是否已无错误退出

我有一个应用程序，在它完成并正常退出后，不应该重新启动。此应用程序完成其业务后，我想关闭实例（ec2）。我正在考虑使用带有选项的systemd单位文件来实现这一点

Restart=on-failure
ExecStopPost=/path/to/script.sh

应在

ExecStopPost

上运行的脚本：

#!/usr/bin/env bash

# sleep 1; adding sleep didn't help

# this always comes out deactivating
service_status=$(systemctl is-failed app-importer) 

# could also do the other way round and check for failed
if [ $service_status = "inactive" ] 
then
  echo "Service exited normally: $service_status . Shutting down..."
  #shutdown -t 5
else
  echo "Service did not exit normally - $service_status"
fi
exit 0

---

问题是，当post stop运行时，我似乎无法检测到服务是否正常结束，然后状态为“停用”，只有在之后，我才能知道它是否进入了

失败

状态。

您的问题是，systemd认为该服务在

ExecPostStop

过程完成之前处于停用状态。睡懒觉也无济于事，因为它只会等待更长的时间。

ExecPostStop

的想法是清理服务可能留下的任何东西，如临时文件、UNIX套接字等。服务未完成，并准备重新启动，直到清理完成。所以，如果你这样看的话，systemd所做的是有意义的

您应该做的是检查脚本中的

$SERVICE\u RESULT

、

$EXIT\u code

和/或

$EXIT\u STATUS

，这将告诉您服务是如何停止的。例如：

#!/bin/sh
echo running exec post script | logger
systemctl is-failed foobar.service | logger
echo $SERVICE_RESULT, $EXIT_CODE and $EXIT_STATUS | logger

允许服务运行到完成时：

Sep 17 05:58:14  systemd[1]: Started foobar.
Sep 17 05:58:17  root[1663]: foobar service will now exit
Sep 17 05:58:17  root[1669]: running exec post script
Sep 17 05:58:17  root[1671]: deactivating
Sep 17 05:58:17  root[1673]: success, exited and 0

当服务在完成之前停止时：

Sep 17 05:57:22  systemd[1]: Started foobar.
Sep 17 05:57:24  systemd[1]: Stopping foobar...
Sep 17 05:57:24  root[1643]: running exec post script
Sep 17 05:57:24  root[1645]: deactivating
Sep 17 05:57:24  root[1647]: success, killed and TERM
Sep 17 05:57:24  systemd[1]: Stopped foobar.

---

systemctl stop foobar.service和kill$（pidof foobar_app）

都会在ExecStopPost上生成success、kill和TERM，foobar会进入“非活动”或死状态。有没有办法区分foobar进入“失败”状态和foobar进入“非活动”状态<代码>$SERVICE\U RESULT、$EXIT\U code和/或$EXIT\U STATUS在这里没有帮助。因此，如果服务正常完成，或者被systemd强制停止，但如果它不是因为systemd停止的原因而失败，您想做些什么？我想特别处理服务失败（核心转储、EXIT\U失败、不可屏蔽信号等）而用户发起的SIGTERMs应该是允许的。特别是，我想知道该服务是否会在ExecStopPost中重新启动$服务\u结果显示为保持“启动限制突发”，但它从未显示该值，即使在配置限制突发间隔和服务达到突发限制之后。在您的情况下，您可以尝试将

SuccessAction=reboot

添加到

单元

部分。如果服务完成并返回0，通过systemctl停止，通过TERM终止，则会触发此操作。如果服务通过SEGV终止或返回非零代码，则不会触发该事件。