2.0 (linux): managed service main thread intermittently busy-loops in user space while idle (~100% of one core, no log/DB output) #51852

Description

On Linux, the managed serve --service process intermittently burns a full core in user space while producing no observable output. Measured on a live process:

user ticks / 10 s : 1001     (100 ticks = 1 core-second -> ~100 % of one core)
sys  ticks / 10 s : 7
log lines / 10 s  : 0
DB writes / 10 s  : 0
RSS growth        : 853 MB -> 880 MB in 30 s

The load is in user space, which is why I am filing this separately from #36311, where the main thread was sampled spinning in the native write path (kernel-side). This may be a different variant.

(The 1001 user ticks measurement above was taken before I reduced host load. It is a historical observation, not the current steady state — see the intermittent samples below for present behaviour.)

Caveat: the spin is intermittent, not constant. Sampling the same process every 5 s over 60 s:

t= 5s  29%   t=35s  40%
t=10s  61%   t=40s   3%
t=15s  47%   t=45s   4%
t=20s  14%   t=50s   4%
t=25s   7%   t=55s   4%
t=30s   4%   t=60s  33%

I am not claiming a permanent wedge — I am reporting a recurring user-space spin that can push /api/info past the liveness window (~6 s in v2.0.18: requestTimeout: 2000 × 3 attempts), which then triggers kill + respawn (see #51216, #37795, #37239).

Correlated observations

Watcher churn in the same log:

The service subscribes to / and /home as type=entries, plus a symlinked skills directory (~/.agents/skills → project .agents/skills → skills-src). Whether that causes the spin or is a co-symptom I did not isolate — the correlation is strong but I did not run a clean A/B.

Also: RSS grew ~27 MB / 30 s while idle.

Distinction from related reports

• serve: idle service burns 20-45% CPU in silent bursts from launch; memory creeps #42299 (macOS) reports idle CPU bursts (20–45 %) with memory creep and no log output — the closest match. My report adds: Linux, a user-space vs kernel split (1001 user ticks vs 7 sys ticks, i.e. ~100 % of one core in userspace), and a direct correlation with file-watcher churn (/ and /home subscribed as type=entries, 8,027 subscribes to a symlinked skills dir) which serve: idle service burns 20-45% CPU in silent bursts from launch; memory creeps #42299 does not cover.
• 2.0: standalone SSE disconnect can wedge Bun server at 100% CPU #36311 sampled the main thread in the native write path (kernel-side, __write_nocancel). Mine is user-space, so it is likely a different variant.
• server: orphaned serve --service busy-loops at 100% CPU in drain retry loop (high energy) #41066 is a drain retry loop after an orphaned service; mine is an idle spin on a live service.
• core: long-lived V2 server enters persistent allocation loop #36677 reports a persistent allocation loop; mine is intermittent and correlated with watcher activity.

If maintainers consider this the same root cause as #42299, I am happy to fold this data into that issue instead.

Suggested investigation

1. Profile the main thread during a spin (perf, or a Bun CPU profile) to identify the hot user-space path.
2. Check whether the / and /home type=entries subscriptions plus symlink traversal are involved.
3. Consider deriving liveness from something request work cannot block (as raised in desktop(win): background service SIGKILLed mid-turn when snapshot capture blocks /api/info for >6s -> ~60s restart loop, aborted turns #51216), so an intermittent spin does not get the server killed.

Workaround

OPENCODE_DISABLE_FILEWATCHER=true. After applying that plus the other load reductions here, the service stayed up 78 min with no restart (previously every 1–4 min).

Plugins

@tarquinen/opencode-dcp@latest, @vheins/opencode-9router, plus local plugins smart-voice-notify, opencode-discord-presence, opencode-vibeguard, opencode-asynchronous-agent.

OpenCode version

v2.0.18 (compiled binary ~/.opencode/bin/opencode, Bun 1.4.0)

Steps to reproduce

1. Run v2.0.18 with the TUI on a loaded Linux host (load avg > 8 on 8 cores), several projects attached, one tree containing a symlinked skills directory.
2. Sample the service main thread: awk '{print $14" "$15}' /proc/<pid>/stat over 10 s.
3. Observe intermittent user-space CPU with no matching log or DB output.
4. In the log, look for Background service is unresponsive → cli starting args=[serve --service] pairs.

Screenshot and/or share link

N/A

Operating System

Linux 6.12.38 (Debian/Kali), x86_64, 8 cores, 16 GB RAM, load average ~10–13, ~10 GB swap in use

Terminal

GNOME Terminal