服务进程脱离任务托管¶

一、现象¶

一个常驻服务，手动在终端里启动之后运行正常，当天下午突然消失。

具体表现：

服务在中午之前一切正常，接口能访问、日志正常增长。
15:32 之后，从别的设备访问服务界面开始返回 502。
去机器上看，进程已经不在了。
服务自己的日志里没有任何异常退出记录——没有报错、没有捕获到退出信号、最后一行还在正常输出。
服务是配置了「开机自动启动 + 看门狗定期探测」的，也就是说它本来应该是被托管的。

关键特征是最后两条的矛盾：日志显示它没有崩溃，但进程确实没了。

当你看到「进程消失了，但没有任何错误日志」，这基本就排除「程序崩溃」这一类原因了——崩溃通常会留下点东西。没有日志的死亡，是有东西在外部把它杀掉了。

二、环境¶

项	情况
操作系统	Windows 主机
托管方式	计划任务（登录时启动）+ 一个每 5 分钟探测健康接口的看门狗脚本
启动方式	当天中午有人手动在交互式终端里直接运行了服务的可执行文件
服务形态	常驻服务，监听本地端口，通过组网被其它设备访问
数据目录	本机固定目录（单实例设计）

出事前一天刚做过一次「手动拉起」，出事后第一次重启也是手动做的——手动操作在这个环境里是常态，这正是问题的来源。

三、原因¶

3.1 直接原因¶

手动从终端启动的进程，属于那个终端会话。终端会话结束，系统会连带清理它的子进程。

这是操作系统的正常行为，不是故障：

系统
 └─ 任务计划服务        ← 托管启动的进程挂在这里，与交互式会话无关
     └─ 托管实例

交互式终端会话          ← 会话结束，下面这棵"树"被清理
 └─ 手动启动的实例

托管启动的进程之所以能长期活着，是因为它挂在任务计划服务下面，不属于任何一个用户会话。而手动启动的进程挂在那个终端下面，终端一关（或会话被清理），它就跟着走了。

3.2 为什么「没有日志」¶

因为杀进程的动作发生在外部，服务自己没有机会感知。进程被强制结束时，它通常来不及写任何东西——尤其是被清理作业对象这种方式，进程可能在完全没有收到可处理信号的情况下就没了。

所以 「日志戛然而止」和「日志里有错误」是两种完全不同的问题，指向完全不同的原因。

3.3 为什么看门狗没救回来¶

看门狗是有的，5 分钟探一次。但它只探测、没有预警机制，而且：

手动拉起的实例不是它启动的那个，两者的进程标识、会话归属都不同。
服务消失后看门狗确实重新拉起了一个，但没有人被告知发生过这件事——于是这次「消失-恢复」在记录上完全没有痕迹。

这才是真正的问题：故障发生了、被自动恢复了、但没有任何人知道。下次它可能发生在一个看门狗没覆盖的场景里。

3.4 三层归因¶

服务消失
  → 为什么？被终端会话结束时的清理动作带走了
    → 为什么它会挂在终端会话下？因为有人手动从终端启动了它
      → 为什么会有人手动启动？因为"手动启动"是这个环境里被允许的、方便的、没人拦的操作  ← 根因

只写到前两层，解决方案会是「下次记得手动启动完别关终端」——**这不是解决方案，这是把系统缺陷变成对人的要求。**写到第三层，解决方案才是「把正确的启动方式变成唯一方便的方式」。

四、解决¶

4.1 已采用的做法¶

托管服务一律通过托管入口重启，不直接运行可执行文件。要手动触发一次重启，就触发那个计划任务。
**需要临时调试时，用独立的数据目录。**在另一个会话里跑一份调试实例，把它的数据目录、监听端口都指向临时位置，与托管实例完全隔离。调试完直接结束会话即可。
把「怎么重启这个服务」写进文档（本文即为此，同时登记到职责与服务目录），让正确做法是查得到的。
给「服务曾经消失过」留痕：看门狗每次恢复动作写一行日志并计数；连续多次恢复要通知人。自动恢复必须留下痕迹，否则它就是在掩盖故障。

4.2 没有采用的方案及原因¶

方案	为什么不采用
让服务自己「守护化」（脱离父进程）	会与托管机制产生两份控制权，反而更难管；正确的做法是用系统自己的托管能力
禁用终端清理行为	需要改系统策略，影响面大，且只解决这一种场景
手动启动后就不管了，靠看门狗兜	掩盖问题，且没有痕迹（见 3.3）
把服务改成前台常驻、专人守着	不可持续

判断标准：好的解决方案应该让错误做法变得不方便。正确做法不需要人记得住。第 1 条就是按这个标准选的——它把「重启」这件事收敛到一个入口。

五、验证¶

① 通过托管入口重启服务
② 确认进程的父进程是任务计划服务
③ 关闭所有交互式终端，等待超过看门狗探测周期
④ 确认服务仍在，且健康接口正常
⑤ 故意手动拉起一个实例（用临时数据目录），确认它不影响托管实例
⑥ 确认看门狗日志里没有"恢复"记录 —— 有的话说明还有别的问题

第 ⑥ 步很重要：「没有告警」才是验证成功的标准。如果验证过程中还看到恢复记录，说明服务仍然在非正常地消失。

六、经验¶

可迁移的判断规则¶

**进程消失了但日志没有异常 → 先怀疑外部清理。**程序崩溃与外部清理的排查路径完全不同。
判断一个常驻服务是否「真的常驻」，看它的父进程和所属会话，不要看「它现在在跑」。「现在在跑」完全不能说明它明天还在。
**任何「手动启动」和「托管启动」并存的系统，一定会有实例归属混乱的问题。**要么统一走托管入口，要么把手动启动限制在隔离的数据目录里。
**自动恢复必须留痕并计数。**一个会静默自愈的系统，会让所有间歇性故障永远查不出根因——因为等你去看的时候，它已经好了。
不要用「对人提出要求」来修复系统缺陷。「下次记得别这么做」不是修复；「让正确做法成为唯一方便的做法」才是。

这个坑最反直觉的地方¶

大多数人会认为「服务没了」意味着「服务挂了」。**在这个场景里，服务从头到尾都是健康的，它只是被搬走了。**先入为主地假设「它挂过」，会让你去翻一个干干净净的日志，然后卡在那里。