macOS 自动更新脚本提前终止，导致更新失败并在下次启动时再次退出

[cindy-issue]

提交人: dummycopy
客户端版本: 0.1.66

---

现象

自动更新补丁下载完成并进入应用阶段后，Cindy 会关闭，但没有自动重新启动。再次手动打开时仍是旧应用，启动数秒后又会主动退出，用户感知为“更新后无法重启，重新打开即闪退”。

复现步骤

1. 使用存在可用更新的旧版 Cindy。
2. 等待补丁下载完成，并满足自动应用更新的条件。
3. Cindy 主进程退出。
4. 等待自动重新启动，但应用没有再次打开。
5. 手动打开 Cindy。
6. 旧版检测到仍然存在的本地补丁，再次进入更新流程并主动退出。

期望行为

• 外部更新器应在主进程退出后可靠存活，完成解压、替换应用并重新启动 Cindy。
• 如果更新器交接或安装失败，应保留可运行的旧版本、明确提示失败，并停止自动退出重试，避免形成启动循环。

实际行为

• 外部更新脚本启动并确认旧主进程已经退出。
• 脚本在“等待文件系统稳定”的固定 2 秒等待阶段提前终止。
• 后续的补丁解压、应用替换和重新启动均未执行。
• 本地补丁继续保留，旧版下次启动后再次执行更新并以正常退出码主动关闭，因此表面上像闪退。

复现频率

在同一设备上连续记录到 28 次更新尝试，28 次均启动了更新脚本，但解压和重启验证次数均为 0；每次都停在同一个阶段。此前同一更新链路曾正常完成。

已尝试

• 手工安装新版本后可以正常启动和使用。
• 已验证应用签名与 Apple 公证有效。
• 已验证应用目录和更新目录具有写权限。
• 已确认自动重启设置处于启用状态。
• 未发现与本次退出对应的系统崩溃报告或 Crashpad dump。

脱敏诊断摘要

• 更新脚本的执行顺序为：等待旧 PID 退出 → 记录“等待文件系统稳定” → sleep 2 → 写更新锁 → 解压补丁 → 替换应用 → open 新应用。
• 所有失败记录均只到 sleep 2 之前；更新锁、解压日志和脚本末尾的自删除均未发生，临时目录中遗留的脚本数量与失败次数一致。
• 主进程诊断记录为 exitCode=0、reason=update-relaunch，说明“再次打开即退出”不是 native crash，而是旧版主动重试更新。
• macOS 分支的 executeUpdateMacOS() 在 spawn('/bin/bash', ..., { detached: true, stdio: 'ignore' }).unref() 后立即调用 forceQuit() / process.exit(0)，没有 updater 启动握手、存活确认或失败回传。
• 现有日志无法确定 updater 收到的具体终止信号或信号来源，因此不应把 Electron、系统进程管理或安全组件中的某一个直接认定为已证实的触发源。

建议排查方向

• 为 macOS updater 增加独立、可验证的生命周期托管。
• 主进程仅在 updater 完成启动握手并确认可独立存活后退出。
• updater 增加信号捕获、退出原因记录和安装结果回传。
• 补充打包后的 Electron 端到端更新测试，而不仅验证生成的 shell 脚本本身。
• 更新交接失败后停止启动时自动重试，并提供恢复或手工安装入口。

---

OS: darwin arm64 (27.0.0)
Harness: Codex
Model ID: gpt-5.6-sol
界面语言: zh-CN

[dash-s-cindy]

判断：macOS 自动更新链路仍值得修复。现有产品已经具备下载并暂存补丁、手动应用、版本匹配清理以及失败重试上限等能力；当前真正需要处理的是外部 updater 与主进程之间的生命周期交接，以及应用失败后的可观测性和恢复行为。Issue 所述“具体由 Electron、系统进程管理还是安全组件终止脚本”目前仍是待验证原因，但“脚本在文件系统稳定等待后没有继续执行”已有源码和历史日志相互印证，足以作为修复入口。

已确认的实现事实

• apps/desktop/src/main/updateService.ts 的 executeUpdateMacOS() 生成脚本后以 spawn('/bin/bash', [scriptPath], { detached: true, stdio: 'ignore' }).unref() 启动，随后立即调用 forceQuit()。主进程没有等待 updater 的启动握手，也没有获得 updater 的阶段状态或失败结果。
• apps/desktop/src/main/updateScriptMacOS.ts 的实际顺序是：等待旧 PID 退出 → 记录“waiting for filesystem to settle” → sleep 2 → 写更新锁 → ditto 解压 → 替换 .app → open 新应用 → 轮询验证新主进程 → 清理临时文件。
• 当前快照已经包含若干保护：patch-info.json 持久化 applyAttempts；checkExistingPatch() 在同一补丁达到 3 次应用尝试后清除补丁并停止启动时重试；脚本也记录解压、替换、启动验证结果。手动入口仍通过更新 banner 触发 relaunch。
• 当前快照已有 apps/desktop/src/main/__tests__/updateScriptMacOS.test.ts：覆盖生成脚本的 Bash 语法、旧 PID 超时升级、bundle helper 清理、替换顺序、启动验证成功/失败等；但测试主要验证生成脚本和受控假应用，不能替代正式签名包上的 Electron→detached updater→退出→替换→重启端到端验证。

需要重点核对的矛盾

Issue 报告连续 28 次尝试，而当前代码对同一持久化补丁设置了 applyAttempts >= 3 的终止保护，并且 incrementApplyAttempts() 位于 updater 启动前。两者不一定互相否定：可能对应不同补丁、不同客户端构建、计数写入失败/被清理，或启动路径并未持续读取同一个 patch-info.json。但在采取修复前必须用 0.1.66 正式包核对每次尝试的补丁版本、计数值、文件时间和启动日志，否则无法确认循环保护是否在真实故障路径生效。

建议行动

1. 先取得维护者确认。 docs/dev-rules/cindy-updater.md 明确规定，任何 updateService.ts、macOS updater 脚本或相关更新链路改动都必须先确认范围、影响和回滚方式；本 Issue 不应直接据此提交未经确认的更新器改动。
2. 固定复现并补齐证据。 使用 0.1.66 macOS arm64 正式签名包，记录自动应用开关、当前/目标版本、patch-info.json、applyAttempts、补丁 SHA/大小、完整 main 日志和 cindy-update.log。同时保留每次遗留的脚本与临时目录，记录退出时间与下一次实例启动时间。
3. 先做最小诊断改动或实验。 在 sleep 2 前后增加明确的阶段标记和退出原因记录；验证脚本是否收到信号、父进程退出后是否仍有存活进程、是否有新 Cindy 实例在替换前启动。不要把某一个信号来源当作已证实结论。
4. 修复优先级放在生命周期交接。 推荐让 updater 具备可验证的启动握手/独立存活确认，再允许主进程退出；updater 应记录阶段结果，并在交接、解压、替换或重启失败时回传可识别结果。安装失败必须保留可运行旧版本、解除更新锁，并让用户进入可恢复的手动安装路径。
5. 覆盖真实打包 E2E。 至少验证：正常替换并重启、updater 在等待阶段被终止、旧 PID 退出延迟、用户在等待窗口重新打开应用、解压/替换失败、open 失败、启动验证超时、连续失败后的重试停止；同时确认 Windows 路径不被无意改变。

暂不建议直接把“启动阶段自动应用补丁”改成“永不自动应用”。该行为在当前源码、测试和历史产品记录中是既有语义；如果产品希望取消，应作为独立且明确确认的策略变更评审，而不是把 Issue 中的建议直接当成既定修复。

相关记录

• #1800：同一 macOS 启动更新链路的前置报告；其后续评论提供了正式包日志，确认 updater 多次停在“waiting for filesystem to settle”之后、未进入解压和替换。本 Issue 提供了更新版本和更完整的稳定复现，应视为该问题的延续证据。
• #1197：已合并的手动更新重启交互改进，说明手动应用入口和 busy 保护已有产品语义；但该 PR 明确未修改 updateService.ts 或 updater 实际执行链，因此不能视为本 Issue 的修复。

[fico-hub]

集群关联(供维护者一并决策):本单与 #3816(macOS 热更新可产生嵌套 Cindy.app 并毁掉外层 bundle)同属 updateScriptMacOS.ts 更新链路,但根因是两个独立的半边——

• 本单:外部更新脚本在主进程退出后的存活/交接问题(「等待文件系统稳定」的固定 2s 等待阶段脚本提前终止 → 不解压不替换不重启 → 旧版检测残留补丁再次退出,形成循环);
• macOS auto-update can create nested Cindy.app and invalidate the outer bundle #3816:脚本活着但替换阶段非原子(rm -rf 未查退出码 + mv 落进未删净的旧目录 → 嵌套 .app)。

我已在 #3816 按 docs/dev-rules/cindy-updater.md 的确认门提交了替换原子性方案(sibling rename + 回滚 + Contents 校验)等 owner 拍板。建议两单一并裁决:更新器是高危专项区,一次设计通关(脚本存活方式 + 原子替换 + 失败可观测/止损循环)比分两次动刀风险低。若 owner 确认,我可把本单的「存活交接 + 失败后停止自动退出重试」并进同一实现;脚本被谁终止(Electron/系统/安全组件)的定界仍需按上方分析取证。