Repository navigation
cli: 'service restart' fails with 'Managed service port ... already in use' and leaves the old service running #59610
Description
Description
With the TUI open (managed service on 127.0.0.1:49374), opencode service set env OPENCODE_LOG_LEVEL debug followed by opencode service restart fails instead of restarting:
Error: Server process exited with code 1
Error: Managed service port 49374 on 127.0.0.1 is already in use by PID 7763 (/home/juanprm/.opencode/bin/opencode serve --service). Configure another port with `opencode service set port <port>` and start the service again.
at <anonymous> (/$bunfs/root/chunk-1z3a4hp2.js:3:7501)
[cause]: ServeError: ... Error: Failed to start server. Is port 49374 in use?
at cli.service.restart
The old service survives, so the new env/log level never applies.
A fresh TUI spawn does apply it: the serve --service child has OPENCODE_LOG_LEVEL=debug in /proc/<pid>/environ and logs level=DEBUG; the TUI process itself does not have the variable, so the child gets it from the service config.
The port is shared across profiles: an isolated XDG_CONFIG_HOME / XDG_DATA_HOME / XDG_STATE_HOME still targets port 49374 and fails against the running PID.
Plugins
None configured: no plugin key in opencode.jsonc and no local plugin directories. The service reports plugins=14 (built-ins).
OpenCode version
2.2.0, channel latest, local=false, standalone install at ~/.opencode/bin/opencode.
Steps to reproduce
- Open the TUI.
opencode service status->http://127.0.0.1:49374;pgrep -af 'serve --service'-> one PID. opencode service set env OPENCODE_LOG_LEVEL debugopencode service get env->{"OPENCODE_LOG_LEVEL":"debug"}opencode service restart-> the port-in-use error above; the old service PID survives.tr '\0' '\n' </proc/<pid>/environ | grep OPENCODE_LOG_LEVEL-> no match; nolevel=DEBUGlines.- Close and reopen the TUI (fresh spawn): the service now has the env and logs DEBUG.
Screenshot
Not applicable; the log evidence is above.
Operating System
Pop!_OS 24.04, kernel 7.2.6-76070206-generic, x86_64.
Terminal
Ghostty (TERM_PROGRAM=ghostty, TERM=xterm-256color, COLORTERM=truecolor), shell /bin/bash.
Additional context
- Before/after:
opencode service status->http://127.0.0.1:49374;pgrep -af 'serve --service'-> PID 7763, parent 7197 (opencodeTUI), started 13:53:43. No second service appears. - Desktop app: not installed or running. No user systemd units. No
XDG_*overrides beyond the session defaults;OPENCODE_SESSION_IDandOPENCODE_TERMINALare set by the TUI. - The env applies when the restart succeeds or when a fresh TUI spawns the service; the failure is the port conflict, which leaves the old process (and its old env) in place.
- Related: service (v2): serve --service daemon keeps using old OPENCODE_API_KEY after the key is rotated (401 with no hint) #42690 (service keeps an old env after it changes), Background service is a per-user singleton: the first launch's env applies to every profile / config dir #58141 (the first launch's env applies to every profile), tui: first draw takes 14.6s on a cold service start #59597.
Activity
opencode-agent commentedon Oct 27, 2026
Thanks for the detailed report. I tried this on 2.2.0 (Linux) and couldn't reproduce it:
opencode service set env OPENCODE_LOG_LEVEL debugandopencode service restart, the newserve --serviceprocess hadOPENCODE_LOG_LEVEL=debugin/proc/<pid>/environ. That was true with and without a TUI open, and when a fresh TUI launch started the service.opencode session listin a repo),level=DEBUGlines such asskill source loadedappeared inopencode.log. So no DEBUG lines right after a restart doesn't by itself mean the level was ignored.--log-levelisn't a v2 CLI flag (only--print-logsexists), so it not reaching the child is expected.OPENCODE_LOG_LEVELis the way to set the level.One way I got exactly what you describe: another
serve --service(e.g. from a differentXDG_STATE_HOME, or one started by the Desktop app) was already holding the service port.service restartthen failed with "Managed service port … already in use", and the process left running didn't have the env.Could you share:
opencode service restart. Does it print a URL or an error?opencode service status, and the output ofpgrep -af 'serve --service'plus each pid's parent (ps -o pid,ppid,lstart,cmd -p <pids>) before and after the restart.XDG_*orOPENCODE_*env overrides.Related: #58141 (the first launch's env applies to every profile), #42690 (the service keeps an old env after it changes), #59597.
[-]cli: 'service set env' values are not passed to the managed serve --service process[/-][+]cli: 'service restart' does not apply 'service set env' values (a fresh TUI spawn does)[/+][-]cli: 'service restart' does not apply 'service set env' values (a fresh TUI spawn does)[/-][+]cli: 'service restart' fails with 'Managed service port ... already in use' and leaves the old service running[/+]Addin commentedon Oct 27, 2026
@opencode-agent
Your port hypothesis is right. The env plumbing is fine; the failure is the restart itself:
Requests:
opencode service status->http://127.0.0.1:49374;pgrep -af 'serve --service'-> PID 7763, parent 7197 (opencodeTUI), started 13:53:43. The restart fails and 7763 survives; no second service appears.XDG_CONFIG_HOME/XDG_DATA_HOME/XDG_STATE_HOMEstill targets port 49374 and fails against 7763, so the port is shared across profiles.XDG_*overrides beyond the session defaults (OPENCODE_SESSION_ID/OPENCODE_TERMINALonly).A fresh TUI spawn does apply the env: the current service 7763 has
OPENCODE_LOG_LEVEL=debugin/proc/7763/environ; the TUI (7197) does not.level=DEBUGlines appear after a project opens.So
service restartcannot replace a running service on the same port; the surviving process keeps its old env, which is why the new level appeared not to apply. Reframed title/body accordingly. Related #42690, #58141.