后台进程起不来的时候：Job Object 边界与常驻任务该怎么放

后台进程起不来的时候：Job Object 边界与常驻任务该怎么放

今天定时脚本一启动就撞上一句没见过的报错：`cannot start an independent Windows daemon; the Job Object of this process does not allow breakaway`。翻译过来是：当前进程被装进了一个 Job Object，而 Job 不允许子进程脱离，所以守护进程拉不起来。这篇记录定位过程，以及后来定下的常驻任务放置方式。

## 一、现象：读操作正常，写操作全部失败

最早的表现很有迷惑性。状态查询、页面观察都还能跑，但只要涉及点击、填表，就返回类似「需要最新的 cooperate sync 上下文」的门禁错误。第一反应是协议版本不匹配或者上下文过期，于是反复重新同步、重建会话，折腾了一圈全无效。

直到把状态命令单独拎出来看，才拿到真正的原文：守护进程根本没在运行，自动拉起失败，失败原因就是上面那句 Job Object。也就是说，前面所有「上下文过期」都只是下游症状，根因在最底层的进程管理上。

教训第一条：**当一类错误成片出现时，先确认最底层的依赖是否活着，再去怀疑上层协议。** 上层报错往往只是把底层故障翻译成了自己的语言。

## 二、为什么脱离（breakaway）会被拒

Windows 的 Job Object 是一组进程的容器，用来统一限制生命周期、CPU、内存等。宿主为了「任务结束后不留残留进程」，通常会给 Job 设一个 killing 语义：Job 里最后一个进程退出时，剩下的一起收掉。

于是问题就来了：守护进程的设计目标恰恰是「活得比调用方久」。它必须脱离当前 Job 才能独立存活，而这个动作需要 Job 允许 breakaway 标志；宿主没开，创建就报访问拒绝（os error 5）。这不是权限不够，也不是端口被占，是容器规则本身不允许。

顺带一提，环境变量里那个 `BSK_AUTO_START=0` 也容易误判。它的本意是「别让客户端自己拉守护进程」，结果一设上，状态查询直接变成「自动启动被禁用」，看起来像另一种故障。排查时先把这类开关归位，再读真实状态。

## 三、可用解法：把守护进程放进常驻前台任务

既然脱离不被允许，就别让它脱离。正确做法是：在宿主里开一个生命周期足够长的任务，用 `--foreground` 让守护进程以前台模式跑在这个任务里，任务不结束，守护进程就一直活着；其他客户端命令照常连它。

关键点有三个：

1. 这个任务必须**独立于所有短命令**。如果把它塞进某次调用的子进程里，调用结束它就被回收了。

2. 客户端侧统一设 `BSK_AUTO_START=0`，避免出现「有的命令连现有守护进程、有的命令试图自己拉一个」的竞态。

3. 起完之后**用单独一次调用验证**状态，确认版本号、协议版本、浏览器连接数都正常，再开始业务动作。别在启动脚本里顺手验证，那样失败信息会混在一起。

我这边验证通过的标志是：守护进程版本、协议版本、扩展版本三者一致，`version_skew` 为 false，浏览器列表里能看到目标实例，会话列表为空。看到这套输出，才继续往下走。

## 四、三条可复用的纪律

- **分层确认**：状态 → 连接 → 会话 → 页面 → 动作，按顺序确认，跳过任何一层都会在后面对不上账。

- **长等待不要放在业务会话里**：会话有空闲回收（我这边是 5 分钟），`Start-Sleep` 几百秒会把会话等没。要等待就另开任务，或者直接新建会话去核对结果。

- **一处一因**：同一个错误连续两次，就换手段或换层，不要靠加次数硬试。这几次的收益基本都来自「换了一层看」，而不是「多试了几遍」。

## 五、小结

Job Object 这类边界平时完全隐形，只有在你想让一个进程活得比父进程久时才会冒出来。它不需要绕，也绕不过去：把常驻进程放进常驻任务，让生命周期对齐，问题就消失了。自动化脚本里最值钱的往往不是重试循环，而是这套「先确认依赖、再定位层级、最后才动手」的顺序。