我正在检查看门狗是如何在systemd中实现的。我看到了一些例子。在这些示例中，我看不到应用程序向systemd发送反馈，即它是活动的。
如果应用程序被冻结，systemd将如何知道并重新启动它？因为在这种情况下，它并没有崩溃，应用程序在那里，但被冻结了。
在服务文件中设置看门狗包括设置具有刷新周期的WatchdogSec密钥。例如，udev服务定义了3分钟的看门狗刷新：
$ cat /usr/lib/systemd/system/udev.service | grep -Ei "(watchdog|execstart)"
ExecStart=/lib/systemd/systemd-udevd
WatchdogSec=3min
设置此密钥时，应用程序应该每3分钟至少向systemd发送一条看门狗刷新消息。这可以用CCD_ 6的sd_notify((API来完成；WATCHDOG＝1">
因此，systemd将终止未及时发送刷新消息的应用程序。它最终将根据手册中描述的服务文件中的其他配置密钥重新启动：
WatchdogSec=
配置服务的看门狗超时。启动完成后，看门狗将被激活。服务必须定期调用sd_notify(3(；WATCHDOG＝1"；(即"保活ping"(。如果两个这样的调用之间的时间大于配置的时间，则服务将处于失败状态，并将使用SIGABRT(或WatchdogSignal=指定的信号(终止。通过将Restart=设置为on failure、on watchdog、on normal或always，服务将自动重新启动。此处配置的时间将传递给WATCHDOG_USEC=环境变量中执行的服务进程。如果为服务启用了看门狗支持，则这允许守护进程自动启用保持活动的ping逻辑。如果使用此选项，则应将NotifyAccess=(见下文(设置为打开对systemd提供的通知套接字的访问。如果未设置NotifyAccess=，则它将隐式设置为main。默认值为0，这将禁用此功能。该服务可以检查服务管理器是否期望看门狗保持活动通知。有关详细信息，请参见sd_watchdog_enabled(3(。sd_event_set_watchdog(3(可以用于启用自动看门狗通知支持。
提示：发送到systemd的看门狗刷新消息可以使用类似strace的工具进行监视systemd通常是进程#1:
$ ls -l /sbin/init
lrwxrwxrwx 1 root root 20 avril 21 14:54 /sbin/init -> /lib/systemd/systemd
$ pidof init
1
以下是我们如何监视systemd udevd进程"发送的刷新消息；greping"；systemd接收到的包含应用程序进程pid的消息(我们使用-tt选项来获得时间戳(：
$ sudo strace -tt -p1 2>&1 | grep pid=`pidof systemd-udevd`
09:01:17.348636 recvmsg(16, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="WATCHDOG=1", iov_len=4096}], msg_iovlen=1, msg_control=[{cmsg_len=28, cmsg_level=SOL_SOCKET, cmsg_type=SCM_CREDENTIALS, cmsg_data={pid=328, uid=0, gid=0}}], msg_controllen=32, msg_flags=MSG_CMSG_CLOEXEC}, MSG_TRUNC|MSG_DONTWAIT|MSG_CMSG_CLOEXEC) = 10
09:02:53.345089 recvmsg(16, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="WATCHDOG=1", iov_len=4096}], msg_iovlen=1, msg_control=[{cmsg_len=28, cmsg_level=SOL_SOCKET, cmsg_type=SCM_CREDENTIALS, cmsg_data={pid=328, uid=0, gid=0}}], msg_controllen=32, msg_flags=MSG_CMSG_CLOEXEC}, MSG_TRUNC|MSG_DONTWAIT|MSG_CMSG_CLOEXEC) = 10
[...]
systemd仅检查PID是否仍然存在。据我所知，没有标准的方法来实现"；自定义看门狗检查"；以验证进程是否没有被互斥锁卡住。例如，您可以将自己的看门狗实现为一个单独的systemd单元，该单元对受监督的进程执行自定义检查。