执行摘要

本次PR通过新增SubprocessWatchdog类，为SGLang调度器子进程添加活跃度监控机制，旨在解决C++级别崩溃（如NCCL超时）导致主进程无法检测的“僵尸服务”问题。变更涉及核心监控逻辑、进程启动集成、信号处理完善及全面单元测试，显著提升系统可靠性，属于有意义的错误修复，建议关注其设计如何重用现有SIGQUIT基础设施避免架构复杂化。

功能与动机

问题根源：Issue #18421详细描述了当调度器子进程因NCCL超时等C++错误触发std::terminate()时，Python异常处理程序无法执行，主进程继续运行但无法处理请求，形成“僵尸服务”状态，仅依赖健康检查会导致长达20秒的故障窗口。

解决方案目标：PR body明确指出需添加监控机制，在子进程异常退出时及时触发清理，引用原文：'When a scheduler subprocess crashes at the C++ level, std::terminate() runs before Python exception handlers, leaving the main process unaware. The service continues accepting requests but cannot process them.' 通过守护线程轮询proc.is_alive()，检测到非零退出码时发送SIGQUIT，复用现有信号处理基础设施进行恢复。

实现拆解

变更按模块拆解如下：
| 模块 | 关键文件 | 核心改动 |
|------|----------|----------|
| 监控核心 | watchdog.py | 新增SubprocessWatchdog类：__init__接收进程列表，_monitor_loop守护线程每秒轮询，_check_processes检测异常退出并调用os.kill(SIGQUIT) |
| 集成层 | engine.py | _launch_subprocesses返回元组增加subprocess_watchdog，_launch_scheduler_processes返回(SchedulerInitResult, scheduler_procs)以供构建watchdog |
| 信号处理 | tokenizer_manager.py | 在running_phase_sigquit_handler中添加if self.tokenizer_manager._subprocess_watchdog is not None: self.tokenizer_manager._subprocess_watchdog.stop()，防止正常关闭误报 |
| 后端适配 | http_server.py、ray/engine.py | 调整函数签名以传递watchdog，Ray后端中scheduler_procs为None仅监控detokenizer |
| 测试验证 | test_subprocess_watchdog.py | 6个测试用例覆盖：健康进程不触发、延迟/立即崩溃检测、多进程中单崩溃、空进程列表处理、正常退出不触发SIGQUIT |

关键代码逻辑示例（来自watchdog.py）：

def _check_processes(self) -> bool:
    for proc, name in zip(self._processes, self._names):
        if proc.is_alive() or proc.exitcode == 0: # 忽略正常退出
            continue
        logger.error(f"Subprocess {name} crashed with exit code {proc.exitcode}. Triggering SIGQUIT...")
        os.kill(os.getpid(), signal.SIGQUIT)
        return True
    return False

评论区精华

review讨论由hnyls2002主导，聚焦于正确性与设计简洁性：

1. watchdog引用存储问题：hnyls2002在http_server.pydiff中评论：

   "Why discard the reference of watch dog? When the server receives a SIGQUIT, I think you also need to stop the watch dog."
   作者在提交2bbc0a01中修复，将watchdog存储到tokenizer_manager._subprocess_watchdog，确保SIGQUIT处理程序可访问。

2. 数据结构设计：针对scheduler_procs是否应放入SchedulerInitResult，hnyls2002指出：

   "This should not be kept in the init result. It is only used in the watch dog building steps."
   作者通过提交0262ae10重构，改为返回元组，避免污染初始化结果数据结构。

3. 测试规范：hnyls2002在测试文件补丁中建议注册方式，后续提交调整测试以符合项目规范。所有讨论点均在迭代提交中解决，体现协作中的设计权衡。

风险与影响

技术风险：

• 并发与异常处理：watchdog守护线程若在is_alive()访问时抛出异常可能被静默吞没，提交741252f9已恢复try/except块记录日志。
• 误报触发：正常退出（exitcode == 0）需明确跳过，代码已处理此边缘情况，但生产环境中信号竞争可能仍需验证。
• 多后端兼容性：Ray后端scheduler_procs为None，仅监控detokenizer；非零rank节点watchdog为None，需确保逻辑一致无遗漏。

影响评估：

• 用户价值：故障检测延迟从健康检查的20秒缩短至秒级，减少服务不可用时间，提升用户体验。
• 系统开销：添加守护线程轮询（默认1秒间隔），CPU开销轻微，设计复用现有SIGQUIT处理，未引入新依赖。
• 团队维护：模块化在watchdog.py中，与现有WatchdogRaw模式一致，便于后续扩展；测试用例为类似监控功能提供参考模板。

关联脉络

• 直接关联：本PR直接修复Issue #18421，该issue详细分析了NCCL超时导致C++ std::terminate()的根因和“僵尸服务”影响。
• 代码演进：提交历史显示18次提交，包括初始实现、修复误报（正常退出处理）、测试调整、引用存储修复、设计重构等，体现多人协作（Simon-Li、hnyls2002、alphabetc1）下的迭代优化。
• 架构趋势：近期历史PR中多聚焦CI、测试、性能优化（如PR #21411融合GDN内核），本PR延续了可靠性改进方向，强调错误检测与恢复，符合系统成熟化演进需求。