Linux systemd.service Type=notify 怎样声明服务初始化完成

如果一个 Linux 服务“进程已经起来了”，但配置加载、监听端口或内部缓存还没有准备好，单纯使用默认的 Type=simple 会让 systemd 很快继续启动后续单元。要把“进程启动”和“服务真正可用”分开，应使用 Type=notify，并让服务在完成关键初始化后发送 READY=1。

本文只讨论这一条就绪通知链路：systemd.service 等待什么、服务进程在哪里发送通知、NotifyAccess 怎样限制来源，以及启动卡住时如何从状态和日志判断原因。

官方地址：https://www.freedesktop.org/software/systemd/man/latest/systemd.service.html

Type=notify 等待的不是进程启动，而是 READY=1

Type=notify 的关键区别是：systemd 会等待服务发送 READY=1，再继续处理依赖于该服务的后续启动任务。这个通知只能由服务代码或等价的通知调用发出，不能只在单元文件里写一行配置就自动产生。

通知消息通过 systemd 提供的通知套接字传递。READY=1 表示启动或初始化已完成；它不是“程序没有崩溃”的心跳，也不等于所有后台任务永久成功。应把它放在监听器、必要配置和必须的本地资源都准备好之后。

单元文件要把通知权限写清楚

下面的单元把通知权限限定为主进程。ExecStart 启动的进程负责发送就绪消息，After 只表达与网络目标的排序关系，不会替代服务自身的 READY 通知。

[Unit]
Description=Ready-aware demo service
After=network.target

[Service]
Type=notify
NotifyAccess=main
ExecStart=/usr/local/bin/ready-demo
Restart=on-failure
TimeoutStartSec=30s

[Install]
WantedBy=multi-user.target

NotifyAccess=main 让主进程拥有发送状态通知的入口。官方文档说明，Type=notify 在缺少合适的 NotifyAccess 时会收紧到主进程范围；把它显式写出来，能让单元文件的意图和进程归属更容易审查。若由辅助进程发送通知，必须重新设计访问范围和进程生命周期，不能只把值改成 all 就认为通知一定会被正确归属。

把 READY=1 放在真正可用的初始化边界

服务代码可以调用 libsystemd 的 sd_notify。示例把配置准备、监听器准备和通知分成三个清晰阶段；这里的输出是帮助理解的预期示意，并非本任务中执行过的结果。

#include 
#include 

static int prepare_service(void) {
    // 这里应加载必需配置、打开监听器并准备服务必须的本地资源。
    return 0;
}

int main(void) {
    if (prepare_service() != 0) {
        // 初始化失败时不要发送 READY=1，让 systemd 保留失败事实。
        fprintf(stderr, "service initialization failed\n");
        return 1;
    }

    // 只有关键资源可用后，才声明服务已经完成启动。
    if (sd_notify(0, "READY=1") 

调用成功后，systemd 才能把该单元从启动中的状态推进到已启动，并继续处理依赖它的任务。若通知由被 systemd 直接拉起的主进程发出，NotifyAccess=main 通常是最小权限选择；若通知者很快退出，systemd 可能无法把消息正确归属到服务，不能用“消息发出过”替代进程生命周期设计。

启动卡住时先看状态，再看通知链路

使用 Type=notify 后，最常见的现象是服务一直处于启动中，或在 TimeoutStartSec 到期后失败。排查时先确认三件事：单元实际加载的是哪份配置、主进程是否走到通知调用、通知是否发生在初始化失败分支之后。

# 重新读取单元文件，避免仍使用旧的加载结果。
sudo systemctl daemon-reload

# 启动服务并查看 systemd 对启动阶段的判断。
sudo systemctl start ready-demo.service
systemctl status ready-demo.service --no-pager

# 查看本次启动的服务日志，重点寻找 READY 调用前的错误。
journalctl -u ready-demo.service -b --no-pager

如果日志只显示进程启动而没有进入可用阶段，优先检查 READY=1 是否被放在了永远不会到达的分支，或主进程是否在初始化后提前退出。若通知来自辅助进程，还要检查该进程发送消息时是否仍然可被 systemd 识别，以及 NotifyAccess 是否与实际发送者匹配。

不要为了让启动命令立即返回而随意改回 Type=simple：那会隐藏初始化未完成的事实。更合理的做法是给必需初始化设置合理的启动超时，并让失败路径返回非零状态；只有当服务确实不需要向 systemd 声明内部就绪边界时，才考虑更简单的类型。

发布前的四项核对

• 单元中使用了 Type=notify，且服务代码确实调用了 sd_notify(..., "READY=1") 或等价接口。
• READY=1 位于必需配置、监听器和关键本地资源完成之后，而不是进程刚进入 main 时。
• NotifyAccess 与发送通知的进程身份一致，辅助进程不会在消息被处理前就退出。
• 用 systemctl status 和 journalctl 能定位初始化失败、通知未到达或启动超时，而不是只看进程是否存在。

两个容易混淆的问题

只写 Type=notify，不发送 READY=1 会怎样？ systemd 不会把初始化完成当成默认事实；服务可能一直停留在启动阶段，直到启动超时或进程退出。

READY=1 能代替健康检查吗？ 不能。它只声明启动阶段已经结束；运行期健康状态、重载协议和 watchdog 是另外的机制，应按服务需求单独设计。

这条配置的核心不是把服务“包装成 notify”，而是让服务代码明确告诉 systemd：关键初始化在此处完成。只要单元类型、通知权限、发送进程和日志排查四处保持一致，后续服务的启动顺序就有了可解释的就绪边界。