systemd服务启用watchdog需配置watchdogsec、restart=on-watchdog、type=notify，并由服务进程周期调用sd_notify("watchdog=1")主动喂狗，否则无效。
在 systemd 服务中启用 Watchdog，关键不是让 systemd 监控进程是否存活，而是让服务进程主动“报平安”。这需要两部分配合：服务单元配置 + 应用代码（或支持喂狗的程序）。
一、服务单元文件中启用看门狗
在 .service 文件的 [Service] 小节里添加以下几项：
-
WatchdogSec=30s：设置心跳超时时间，例如 30 秒。systemd 会在此时间内等待服务发送
WATCHDOG=1信号；超时未收到即判定服务异常。 - Restart=on-watchdog：指定仅在看门狗超时触发时重启服务（不响应崩溃、退出等其他事件）。
- RestartSec=5s：重启前等待 5 秒，避免频繁重启。
-
StartLimitIntervalSec=60 和 StartLimitBurst=3：限制 60 秒内最多重启 3 次；超过后可配合
StartLimitAction=reboot-force强制整机重启（慎用）。 -
Type=notify：必须设置此项，否则 systemd 不会监听
sd_notify()发送的信号。
二、服务进程必须主动“喂狗”
仅配置 WatchdogSec 不起作用——systemd 不会替你发心跳。你的服务程序需在运行中周期性调用 sd_notify("WATCHDOG=1")。
- 推荐喂狗间隔为
WatchdogSec值的一半（如设 30s，则每 15s 喂一次），留出安全余量。 - C/Go/Python 等主流语言均有对应封装：
systemd库（C）、github.com/coreos/go-systemd/v22（Go）、systemd-python（Python）。 - 若用 shell 脚本启动的服务，可借助
systemd-notify --watchdog命令（需确保NOTIFY_SOCKET环境变量有效）。
三、验证是否生效
部署后检查三件事：
- 运行
systemctl show myservice.service | grep -i watchdog，确认WatchdogUSec显示为设定值（如 30000000）。 - 查看服务日志：
journalctl -u myservice -f，正常应看到 “WATCHDOG=1” 类似记录（取决于应用是否打印）。 - 手动模拟卡死：暂停喂狗（如注释掉通知逻辑或加长 sleep），等待超时后观察服务是否按
Restart=on-watchdog规则重启。
四、常见误区提醒
注意几个高频问题：
- WatchdogSec 不是“服务健康检查间隔”，它只是心跳截止时限；真正的健康逻辑（比如检测数据库连通性、HTTP 接口响应）必须由服务自己实现并决定是否继续喂狗。
-
Type=notify 是硬性前提：设成
simple或forking时，sd_notify()会被忽略，看门狗形同虚设。 -
不要和硬件看门狗混淆：这是用户态服务级看门狗，保护单个服务；若要整机防死锁，需配置
RuntimeWatchdogSec在/etc/systemd/system.conf中。
