multiprocessing.Manager()服务进程终止引发的应用异常及解决方案咨询

问题背景 #

我正在开发首个多进程应用，遇到以下问题：

• 当操作系统因OOM或手动发送SIGKILL终止multiprocessing.Manager()生成的服务进程时，部分子进程会随之终止，导致应用进入异常状态
• systemctl无法按预期重启应用
• 曾尝试实现看门狗子进程监控同级进程及Manager服务进程，但该看门狗会随Manager进程一同终止

现有可选方案：

1. 在父进程中实现看门狗功能
2. 让子看门狗通过sd_notify() API向systemd发送保活信号，配置systemd无信号时重启服务

请问是否有其他方案？哪种最优及原因？

额外可选方案 #

方案3：Manager进程与业务子进程解耦，独立systemd单元管理 #

将multiprocessing.Manager对应的服务进程单独注册为一个systemd单元，业务子进程作为另一个独立单元，通过UNIX套接字、共享内存等IPC方式通信。Manager进程异常时，systemd会单独重启它，业务子进程可在Manager恢复后重新建立连接，避免被连带终止。

方案4：进程组隔离 #

启动multiprocessing.Manager和业务子进程时，将它们放入不同的进程组。通过在子进程启动时调用os.setpgrp()设置独立进程组，这样Manager进程被终止时，操作系统不会将信号传播到其他进程组的子进程，避免连带终止。

最优方案分析 #

优先选择方案2：子看门狗+systemd sd_notify #

原因如下：

1. systemd原生支持，逻辑简单可靠：systemd的看门狗机制是为服务可靠性设计的，配置WatchdogSec参数后，只要看门狗子进程定期通过sd_notify()发送WATCHDOG=1信号，systemd就会自动检测服务状态，超时则重启整个服务，从根源解决应用异常无法自动恢复的问题。
2. 避免看门狗被连带终止：启动看门狗子进程时调用os.setpgrp()设置独立进程组，就能避免它随Manager进程被SIGKILL终止，持续监控整个应用集群状态。
3. 适配OOM场景：通过调整看门狗进程的oom_score_adj参数降低其OOM优先级，可避免被OOM killer优先终止，确保监控不中断。

其他方案的局限性 #

• 方案1（父进程看门狗）：若父进程自身异常挂掉，看门狗也会失效；且父进程需同时监控Manager和所有业务子进程，逻辑复杂度高，易出现监控遗漏。
• 方案3（独立systemd单元）：需拆分服务单元，增加部署复杂度，且IPC通信需额外处理重连逻辑，对首次开发多进程应用的开发者学习成本较高。
• 方案4（进程组隔离）：仅能解决信号传播导致的连带终止问题，无法应对OOM场景下业务子进程被意外终止的情况，且手动管理进程组易出现配置错误。

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