C++ 本身不提供守护进程高可用与自我修复能力，必须依赖 systemd 等外部机制；应专注业务健壮性，如响应 SIGTERM、调用 sd_notify()，禁用自研看门狗或 daemon()。
直接说结论：C++ 本身不提供守护进程的高可用与自我修复能力，这些必须由外部机制（如 systemd、supervisord）或进程内冗余逻辑组合实现；强行在单个 C++ 进程里“自己监控自己”，本质上不可靠，且违背守护进程设计原则。
为什么不能靠 fork() + while(1) 实现自我修复
常见误区是让主进程 fork 出子进程后，父进程循环检查子进程状态并 waitpid() + fork() 重启。这存在几个硬伤：
- 父进程一旦崩溃或被
kill -9，整个恢复链就断了——它自己就是单点故障 - 父子进程共享文件描述符、信号处理等上下文，容易引发资源泄漏或信号竞争
- 无法区分“进程退出”是正常终止、OOM kill、core dump 还是 segfault，盲目重启可能掩盖真实问题
- 没有心跳检测、健康探针、依赖服务就绪判断等工业级指标，所谓“修复”只是机械拉起
systemd 是当前 Linux 生产环境最可靠的选择
现代 Linux 发行版默认使用 systemd 管理长期运行服务，它天然支持守护进程所需的全部高可用语义：
-
Restart=on-failure：仅在非零退出、被信号终止（不含SIGTERM）、超时等场景重启 -
RestartSec=5：控制重启间隔，避免雪崩式重启 -
StartLimitIntervalSec=60和StartLimitBurst=3：限制单位时间内的启动次数，防住反复崩溃 -
WatchdogSec=30+ 进程内定期调用sd_notify("WATCHDOG=1")：实现真正的存活心跳，超时未上报则强制重启 - 自动管理日志（
journalctl -u your-service）、资源限制（MemoryMax、TasksMax）、依赖顺序（After=network.target）
你的 C++ 程序只需做两件事：正确响应 SIGTERM（优雅退出），并在主循环中按需调用 sd_notify()。其余全部交给 .service 文件配置。
立即学习“C++免费学习笔记（深入）”；
C++ 进程内该做什么，不该做什么
守护进程框架的“C++ 部分”应聚焦于业务健壮性，而非系统级可靠性：
- 必须实现：信号安全的清理逻辑（
sigaction(SIGTERM, ...)，禁用malloc/std::cout在信号 handler 中） - 建议实现：
sd_notify("READY=1")标记就绪、sd_notify("STATUS=...")上报状态、定期sd_notify("WATCHDOG=1") - 避免实现：进程看门狗线程、双进程热备、自研 PID 文件锁竞争逻辑——这些已被 systemd 完全覆盖且更稳定
- 不要手动
daemon()或多次fork()：systemd 启动的服务默认以 daemon 模式运行，调用daemon(1,0)反而会干扰其进程树管理
示例关键片段（需链接 libsystemd）：
#include <systemd/sd-daemon.h>
// ...
if (sd_notify(0, "READY=1") < 0) { /* 日志警告，但不中止 */ }
while (running) {
do_work();
if (sd_notify(0, "WATCHDOG=1") < 0) { /* 记录错误，继续循环 */ }
std::this_thread::sleep_for(10s);
}
真正难的是定义“健康”：是 TCP 端口可连？是内部队列积压低于阈值？是数据库连接活跃？这些业务指标必须由你自己的代码判断，并通过 sd_notify("STATUS=...") 或外部 probe（如 HTTP /healthz）暴露。systemd 不懂你的业务，它只负责执行你声明的策略。
