Repository navigation
控制面停机：tsx 下信号重复、持锁连接 idle_timeout、stack.sh 等满 60 秒 #90
Description
#85（单实例锁和优雅停机）合并后复核时发现三件小事，都不挡合并，生产（node 直接做 PID 1）不受影响。
- tsx 父进程下，一次信号偶尔被算成两次。 已证实，偶发。
- tsx 4.23.13 的
relaySignals收到信号后，只等子进程 30ms 的 IPC 回报，等不到就再转发一次。 main.ts把「停机中又收到信号」当作强退，于是 stack.sh 的kill -TERM -- -pgid、desktop prove 的process.kill(-pid)、pnpm dev下的 Ctrl+C，偶尔会以 1 退出，优雅停机被截断。- 实测
pnpm start加 SIGTERM，5 次出现 1 次；pnpm dev加 SIGINT 那次，电脑留在 online。 - 建议：同一信号在约 1 秒内重复到达时忽略。
- tsx 4.23.13 的
instance-lock.ts的 client 没显式写idle_timeout: null。 推测，没实测。- postgres.js 会从
PGIDLE_TIMEOUT或 URL 的?idle_timeout=读这个值。真有人设了，持锁连接会在空闲时被关，控制面就会周期性自己退出。 - 补一行就能挡住。
- postgres.js 会从
- stack.sh entry2 被单实例锁拒绝时，要等满 60 秒才报错。 推测，读脚本得出。
wait_code不检查进程是否已经退出。- 建议：进程退了就立刻打印日志尾巴。
🤖 Generated with Claude Code
Activity
joesmart commentedon Oct 23, 2026
补一条：在最终 main（c6f262d）上跑全套 control-plane 测试，
test/health.test.ts「健康检查不用登录，库连得上回 200，库断了回 503，库回来又是 200」偶发卡满 30 秒超时。Test timed out in 30000ms，不知道卡在哪一步。推测（未证实）：库被掐断后，
/api/health的SELECT 1要等连接池重新连，connect_timeout用的是 postgres.js 默认的 30 秒，满负载下连接被拒得慢，就把用例的 30 秒耗完了。这和 #85 线上记下的「库被隔开时 health 会挂 30 秒」是同一个缺口。建议给健康检查的查询加一个短超时（比如 2 秒），超时就当作连不上库，回 503。这样编排器能更早发现，用例也不会再卡住。🤖 Generated with Claude Code
https://claude.ai/code/session_01Be3SZps2JjqvyrJ1vbLmni
健康检查查库 2 秒没回就回 503，库被隔开时不再跟着挂住 (#90)
单实例锁连接关掉空闲超时，锁被拒时告诉人怎么办 (#90)
stack.sh 等服务就绪时进程组一退就报错，不再等满 60 秒 (#90)
健康检查查库 2 秒没回就回 503，库被隔开时不再跟着挂住 (#90)
单实例锁连接关掉空闲超时，锁被拒时告诉人怎么办 (#90)
stack.sh 等服务就绪时进程组一退就报错，不再等满 60 秒 (#90)
joesmart commentedon Oct 24, 2026
#98 修掉了三项里的两项，提交 f00e706、0db90c0、76ba537：
idle_timeout: 0；锁被拒时提示先停掉另一个，或在工作树里跑pnpm db:own建自己的库（加 pnpm db:own：每个工作树一个自己的库 (#95) #96）。stack.sh等就绪时进程组一退就报错，不再等满 60 秒（63.41s → 1.86s）。还没做：tsx 下信号重复那一项，以及连接层的根因（postgres.js 3.4.9 的
closed()不清query/errorResponse，见 #100）。issue 保持开。🤖 Generated with Claude Code
控制面停机时同一信号 1 秒内到第二遍算同一次，tsx 和 pnpm 转发不再把优雅停机截成强退 (#90)
控制面停机时同一信号 1 秒内到第二遍算同一次，tsx 和 pnpm 转发不再把优雅停机截成强退 (#90)