officerdev/platform
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

vnc: reclaim the port before starting, and do not trust a listener we did not spawn

Browse Source 
Closes the TODO item about orphaned/duplicated VNC servers across sidecar restarts. The diagnosis
there was correct and outlived the move off x11vnc, because the shape of the bug is in the lifecycle,
not the server: the running desktop lives in module state, a sidecar restart forgets it while the
process keeps running, and waitForPort accepted ANY listener on 5900 as proof of a healthy start.
The next start would then spawn a server that could not bind the port, see the ORPHAN listening, and
report success — leaving the platform convinced it had started a desktop the browser was not
looking at.

Two changes. reclaimPort frees the port before spawning: TERM whatever holds it, KILL after two
seconds. waitForPort now also fails when the process we spawned has exited, so a foreign listener
cannot be mistaken for our own.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
pastilhas
2026-08-01 21:22:30 +00:00
co-authored by Claude Opus 5
parent 83bf746ab8
commit f22c667502
2 changed files with 37 additions and 13 deletions
Download Patch File Download Diff File Expand all files Collapse all files
TODO.md
+7 -9
View File
@@ -105,15 +105,13 @@ it exists in the reference app, so none of it was in scope for parity.
paths and an outdated package name, so `installPi` always fires and floods the logs with
`EEXIST` noise. Should detect `@earendil-works/pi-coding-agent` at the real npm prefix.
- [ ] **VNC mirror can orphan/duplicate x11vnc across sidecar restarts.** `vnc-manager.startSession`
tracks the running mirror in module-level state and skips spawning only if that pid is alive.
On a vnc-sidecar restart the state resets to null while the old x11vnc keeps running orphaned;
the next `startSession` spawns a second one. Worse, `waitForPort` treats *any* listener on 5900
as success, so the platform can believe it started a mirror that is actually a stale process —
desyncing into multiple contending x11vnc instances on `:0` (suspected cause of click-lag on
2026-07-16, cleared by killing all but one). Fix: before spawning, kill any existing
`x11vnc -display :0` / free port 5900 (an `ExecStartPre`-style cleanup, like the old
officer-vnc.service unit did with `vncserver -kill`).
- [x] **VNC mirror can orphan/duplicate x11vnc across sidecar restarts.** FIXED 2026-08-01 in the
Xvnc rewrite. The diagnosis was right and survived the move off mirroring: the running desktop is
tracked in module-level state, so a sidecar restart forgot it while the server kept running
orphaned, and `waitForPort` treated ANY listener on 5900 as success — so the next start reported
success while the browser talked to the stale process. Now `reclaimPort` frees 5900 (TERM, then
KILL after 2s) before spawning, and `waitForPort` also fails if the process we spawned has
exited, so a listener that is not ours can no longer be mistaken for a healthy start.
## Infra (alpha)