Activity

1. opencode-agent commented on Oct 22, 2026

   

   opencode-agentBot

   on Oct 22, 2026 – with OpenCode Agent

   Contributor

   More actions

   Thanks for the detailed timeline and code pointers. I couldn't reproduce the false positive here, because it needs a real Windows host sleep with OpenCode running inside WSL2, which this sandbox can't do.

   What I tried on 2.1.0 with a real opencode serve --service:

   • Simulated suspend: I paused the service and a client in the middle of Service.ensure() (the code that probes the service and replaces it if it seems unresponsive) for 30 s, then resumed both. The client reused the existing service; the PID didn't change and nothing was killed.
   • Service actually not answering: when only the service is paused, so /api/info really gets no reply for about 7 s, the client does start its recovery: it sends SIGTERM and replaces the service. That is the "service is really hung" case tracked in service: recovery loop spawns unbounded serve processes when service becomes unresponsive #57038 and desktop(win): background service SIGKILLed mid-turn when snapshot capture blocks /api/info for >6s -> ~60s restart loop, aborted turns #51216.

   So on Linux loopback I couldn't trigger the stale keep-alive socket theory. Whether it happens likely depends on what WSL2 does on resume (VM pause, clock jump, virtual network re-initialisation), or on the service being briefly busy after resume (your log shows MCP connections dropping just before), so it answers /api/info too slowly. This needs a maintainer with a WSL2 laptop to check.

   If you can, these would help narrow it down:

   • Do you see any /api/info request in the server log between resume and the SIGTERM? That would show whether the probes reached the server at all.
   • Does it still happen without the MCP servers or plugins that reconnect on resume?

   Related issues:

   • Infinite "Restarting service.." for OC v2 (on Windows) #57864: endless "Restarting service.." after waking from sleep on Windows
   • Choose another directory to continue this session everytime i sleep windows #58000: the session asks for another directory after every Windows sleep
   • desktop(win): background service SIGKILLed mid-turn when snapshot capture blocks /api/info for >6s -> ~60s restart loop, aborted turns #51216: service SIGKILLed when /api/info is blocked for more than 6 s
   • service: recovery loop spawns unbounded serve processes when service becomes unresponsive #57038: unbounded respawn loop when the service really is unresponsive
   • cli(win): 45s event-stream idle watchdog restarts the managed service, aborting all sessions/subagents #52049: the 45 s event-stream idle watchdog restarts the managed service
2. AlexeyShirshov commented on Oct 22, 2026

   

   AlexeyShirshov

   on Oct 22, 2026

   Author

   More actions

   Confirmed on 2.1.2 (latest, local=false), and it no longer needs a real suspend to reproduce.

   The shipped bundle still contains the same recovery policy — requestTimeout: 2000, if (count >= 3) → PtyHandoff.clear() → SIGTERM → SIGKILL → recruitNow(), and the probe is still a plain fetch("/api/info") with no control over connection reuse.

   Deterministic repro against the installed 2.1.2 binary, in an isolated XDG_* sandbox on port 49400 (a second serve --service with its own state dir, so the real service is untouched). Instead of suspending the host, the test process is frozen with SIGSTOP: it is alive, accepts TCP, but answers nothing — the same shape as a service that just came back from suspend.

   registered pid=178973
   froze pid=178973 at 17:34:17
   WARN ... message="Background service is unresponsive; recovery cannot preserve persistent terminals"
   RESULT: frozen pid was KILLED
   api exit=0 after 13.6s   -> registration now points at a new pid on the same port
   

   Timing matches the live incident exactly:

   • 6 s after the freeze → 3 × 2 s probes counted, "unresponsive" verdict
   • +5 s → SIGTERM cannot be handled by the frozen process, so SIGKILL, then a replacement serve --service
   • the calling client (opencode api get /api/info) exits 0 and returns the new pid, so nothing surfaces to the user — only the running turn and persistent terminals are lost

   Ran it three times: 11.8 s / 11.1 s / 13.6 s, the frozen process was killed every time. The live occurrence (16:51 local, WSL2) had the same 6 s to verdict and the same SIGKILL-then-respawn sequence.

   Also still true: the recovery branch calls PtyHandoff.clear(), so a restart triggered this way can never preserve persistent terminals, even when the old server is merely slow rather than dead.
3. cevr commented on Nov 12, 2026

   

   cevr

   on Nov 12, 2026

   More actions

   Upstream text (not posted yet)

   Upstream still has this: Service.ensure evicts the registered service after three timed-out probes. It came in with
   PR #40896 ("fix(client): evict unresponsive service", merged 2026-08-06), and upstream/dev was unchanged on
   2026-11-12 (git diff HEAD upstream/dev -- packages/client/src/effect/service.ts shows only our fork's onWait
   lines). There is no newer upstream code to take.

   Issue #58111 ("healthy background service is killed after host sleep because probe timeouts count as unresponsive",
   open) reports the same root cause, through host sleep. Post this as a comment on #58111, not as a new
   issue. Also link it from #54810 (slow startup turns into a spawn/retry storm), which overlaps.

   ---

   The same eviction also fires without sleep: a loaded host is enough. On a Linux box at load 20–60, a service that is
   booting or busy misses three 2 s /api/info probes. Any opencode api … call then runs Service.ensure. It
   SIGTERMs the live service, then spawns a replacement, and the replacement is slow too. So the next CLI call kills
   that one as well.

   From one host's opencode.log on 2026-11-12, 00:00–19:03 UTC:

   • 19 server runs started.
   • 6 of them came 3–6 s after a Background service is unresponsive; recovery cannot preserve persistent terminals
     warning that a client logged:
     • five from opencode api POST /api/rpc/… calls made by health and status scripts;
     • one from a TUI opening a session (opencode -s <id>).
   • In the 18:34–18:41 window the service restarted six times in seven minutes.

   What I'd expect. A client never stops a service it did not start just because probes are slow. A slow probe
   does not prove the service is hung: it can be booting, under load, or behind a stale socket after sleep (#58111). The
   client could say that it is waiting (onWait), keep waiting up to its existing deadline, then fail with an error
   that says the service was left running and names opencode service restart. A user who wants a hung service gone
   can still stop or restart it explicitly; that path is Service.stop, which this change leaves as it is. A contender
   that this same ensure call spawned and that then stops answering can still be evicted as today.

   What we run in our fork.

   • packages/client/src/effect/service.ts and promise/service.ts: when a probe times out and the registered pid is
     not a live contender of this call (contenderPool().owns(pid)), ensure reports it, keeps polling until
     promiseTimeout, and recruits no contender against it.
   • If the service never answers, ensure fails with: "Background service at (pid N) did not answer within 120s.
     It was left running; if it is stuck, restart it with opencode service restart."
   • Tests in test/service.test.ts and test/promise-service.test.ts:
     • a service whose first five probes answer after the timeout survives, and is reused;
     • a hanging service is reported and left running, and no contender is spawned.
     • These replace "evicts an unresponsive registered service before starting its replacement".

   Fork commits: f0c6c66 (tests), 05cdc54 (fix) on cevr/opencode branch api-probe-kill. Happy to open a PR.