linux下程序崩溃后应交由systemd管理，通过restart=always、restartsec=1、startlimitintervalsec=60和startlimitburst=5等配置实现安全自动重启，并按错误类型区分重试策略，如网络请求中econnrefused可重试而http 400不可重试。
程序崩溃后如何自动重启进程
Linux 下最直接的方式是用守护脚本配合 systemd 或简单 shell 循环，但要注意避免无限 fork 和资源耗尽。不建议在 C++ 里自己 fork() + exec() 做双重守护——出错点太多，比如信号继承、文件描述符泄漏、子进程僵死。
推荐做法：把主程序做成无守护的普通进程，交由 systemd 管理。写一个 .service 文件，关键配置项包括：
-
Restart=always（进程退出即重启） -
RestartSec=1（失败后 1 秒再试，防高频闪退） -
StartLimitIntervalSec=60和StartLimitBurst=5（60 秒内最多启动 5 次，超限则 stop） -
Environment="LD_PRELOAD=/path/to/your_crash_hook.so"（可选，用于注入 crash 日志）
这样既干净又可控，systemctl status your-app 能直接看到重启次数和最近日志。
关键任务失败后怎么安全重试
重试不是简单套个 while 循环，重点是控制边界、避免雪崩、区分错误类型。比如网络请求失败，ECONNREFUSED 可以重试，HTTP 400 就不该重试。
实操建议：
- 用指数退避：
sleep(1 ，上限设为 8 秒（即最多重试 4 次：1s → 2s → 4s → 8s） - 每次重试前检查是否还该继续：调用
std::this_thread::sleep_for()前先判断shutdown_requested标志位 - 记录失败原因：把
errno或异常字符串写进日志，否则重试 10 次都失败，你根本不知道卡在哪 - 不要在构造函数或析构函数里重试——异常路径下状态不可靠
示例片段：
for (int i = 0; i <h3>如何捕获未处理异常并触发自愈动作</h3><p>C++ 默认未捕获异常会调用 <code>std::terminate()</code>，此时栈已开始销毁，不能再做复杂操作。想记录日志或发告警，必须提前拦截。</p><div class="aritcle_card flexRow artxards"> <div class="artcardd flexRow"> <a class="aritcle_card_img" rel="nofollow" href="/xiazai/gongju/2823" title="C++14"><img src="https://img.php.cn/upload/manual/001/431/639/6ac8b33c327c4749.png" alt="C++14" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a> <div class="aritcle_card_info flexColumn"> <a rel="nofollow" href="/xiazai/gongju/2823" title="C++14" class="overflowclass">C++14</a> <p class="overflowclass">C++14 对 C++11 的修正与增强版本，适合旧系统维护和较老工具链兼容。</p> </div> <a rel="nofollow" href="/xiazai/gongju/2823" title="C++14" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span> </a> </div> </div><p>正确姿势：</p>
- 全局设置
std::set_terminate()，里面只做最小动作：写入紧急日志文件（用write()系统调用，绕过 C 运行时）、触发信号（如raise(SIGUSR2)）、然后调用_exit(128 + SIGABRT) - 不要在 terminate handler 里调用
std::cout、malloc、std::string构造——它们可能已失效 - 配合
signal(SIGABRT, ...)捕获崩溃信号，但注意：signal()处理器里只能调用 async-signal-safe 函数（write、_exit、siglongjmp等）
真正“自愈”不在 terminate 里做，而靠外部机制（如 systemd 自动拉起）完成。
共享内存或文件锁冲突导致初始化失败怎么办
很多“自愈”逻辑卡在启动阶段，比如尝试打开已存在的 /dev/shm/myapp_state 失败，或 flock() 返回 EWOULDBLOCK。这不是程序 bug，而是上一次没正常退出留下的残留。
应对策略：
- 启动时检测共享内存段是否存在且有效：用
shm_open()+fstat()查看 mtime 或自定义 magic 字段 - 文件锁场景下，加超时：用
fcntl(fd, F_SETLK, &lock)失败后，usleep(100000)再试，最多 3 次；超过就认为旧进程僵死，主动unlink()锁文件（需确保其他实例也遵守同一协议） - 避免依赖“清理代码”：不要指望
atexit()或全局对象析构能删掉 shm —— crash 时它们根本不会执行
真正健壮的做法是把初始化失败当作常态来设计，而不是当成异常。
自愈不是让程序在崩溃现场强行续命，而是快速失败 + 可控重启 + 状态隔离。最难的部分永远不是代码怎么写，而是界定哪些状态必须清零、哪些可以保留，以及怎么让上下游系统理解“这次重启不是故障，而是预期行为”。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
