systemd重启后未接收systemd-notify READY=1致服务启动超时问题

针对你遇到的systemd服务首次启动超时、重启后正常的问题，核心原因是systemd 237版本在系统启动初期，内部notify通信机制尚未完全就绪，导致服务过早发送的READY=1通知无法被接收。以下是具体的排查和解决方法：

配置层面优化：补充核心依赖 #

检查服务配置文件的[Service]段，添加必要的依赖项，确保服务在systemd核心组件就绪后再启动：

[Service]
...
Type=notify
Restart=always
RestartSec=10
NotifyAccess=all
WatchdogSec=20s
TimeoutStartSec=30s
# 新增依赖，确保systemd核心日志服务就绪后再启动
After=systemd-journald.service
Requires=systemd-journald.service
...

systemd-journald是systemd的核心组件，依赖它可以保证systemd内部的socket通信路径已完成初始化。

脚本层面优化：可靠的通知前置检查 #

避免盲目使用sleep，改为在脚本中主动验证systemd是否准备好接收通知，修改后的脚本如下：

# 等待NOTIFY_SOCKET环境变量存在且可写
while [ -z "$NOTIFY_SOCKET" ] || ! [ -w "$NOTIFY_SOCKET" ]; do
    sleep 0.5
done

# 测试发送状态通知，确认systemd可接收
until systemd-notify STATUS="Service initializing..."; do
    sleep 0.5
done

# 发送就绪通知
systemd-notify READY=1

while : ; do
  systemd-notify WATCHDOG=1
  sleep 5
done

这段代码会先确认notify通信的socket可用，并且能成功发送测试通知后，再发送READY=1，比固定时长的sleep更灵活可靠。

根本解决：升级systemd版本 #

systemd 237是较旧的版本（对应Debian 9等发行版），后续版本（如245+）修复了大量启动初期的notify通信bug。如果系统环境允许，升级systemd到稳定的新版本可以彻底避免这类问题。

为什么第二次启动正常？ #

首次启动时系统刚完成重启，systemd正在初始化大量系统服务和内部组件，notify通信的socket尚未完全就绪；第二次启动时systemd已处于稳定运行状态，能正常接收服务发送的通知，因此启动成功。

内容的提问来源于stack exchange，提问作者einzuk