双进程互保在Linux上不可靠，因内核不支持进程免杀，kill-9对普通进程总有效；其本质是检测重启而非防终止，且面临信号丢失、僵尸残留、权限隔离等问题，systemd的Restart=on-failure更可靠。
为什么双进程互保在 Linux 上实际不可靠
Linux 内核不提供“进程无法被杀死”的机制，kill -9 对任何普通进程都有效。所谓“互保”，本质只是快速检测 + 重启，而非阻止终止。试图用 prctl(PR_SET_PDEATHSIG) 或 waitpid() 监控对方退出，会遇到信号丢失、僵尸进程残留、权限隔离（如不同用户/namespace）等现实问题。真正能绕过 kill -9 的只有内核模块或 init 进程（PID 1），但这两者都不属于用户态守护进程范畴。
用 fork + pipe 实现基础心跳检测（无 root 权限可用）
两个进程通过匿名管道单向通信，定期写入时间戳；对方读取并比对间隔。超时即认为异常，触发重启。这种方式不依赖信号，规避了 SIGCHLD 丢失风险。
- 进程 A 启动后
fork()出进程 B，同时创建pipe(fd[2])，将fd[1]（写端）传给 B，A 保留fd[0]（读端） - B 每 3 秒调用
write(fd[1], &now, sizeof(now))，A 用read(fd[0], &last, sizeof(last))非阻塞读取（设O_NONBLOCK） - A 检测到连续 2 次读失败或时间差 > 5 秒，执行
kill(B_pid, SIGTERM)后fork()+exec重启 B - 同理，B 也需持有 A 的 PID 并做对称检查（需额外共享内存或文件记录 PID）
systemd 里用 Restart=on-failure 更实际
手动实现双进程互保极易陷入竞态和资源泄漏。现代 Linux 发行版默认使用 systemd，它原生支持进程崩溃后自动拉起，且比用户态逻辑更可靠：
- 在
/etc/systemd/system/mydaemonA.service中设置：[Service] Restart=on-failure RestartSec=2 Type=simple ExecStart=/usr/local/bin/mydaemonA
- 同理配置
mydaemonB.service，并用After=mydaemonA.service和Wants=mydaemonA.service建立启动依赖 - systemd 本身由 PID 1 管理，不受
kill -9影响，且能捕获所有退出状态（包括 OOM killer 终止）
真正需要互保时，必须接受“重启有延迟”这个事实
无论用管道、socket 还是 inotify 监控 pidfile，检测+拉起至少耗时 100ms～2s。如果业务要求“零中断”，应该重构为单进程多线程/多 worker 模式，配合 sigwaitinfo() 处理信号、mlockall() 锁定内存防 swap，而不是把希望寄托在两个进程互相拉对方一把。另外，kill -9 往往是运维误操作或系统资源彻底耗尽的征兆——此时强行复活进程只会加剧雪崩。
立即学习“C++免费学习笔记（深入）”；
