fix(kvm): one desktop-tab owner per seat via advisory lock (VA-108) #112
Loading…
Reference in a new issue
No description provided.
Delete branch "fix/VA-108-single-kvm-owner-per-seat"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Two vervain-agent instances can run on one host: the root system service (attaches to seat0's active session, VA-84/VA-107) and a per-user instance started by systemd --user at login. Both expose the desktop tab, so both could open a portal RemoteDesktop session, grab a uinput device, and drive XTEST on the same seat at once: double input injection, competing portal sessions, duplicated capture. The root cause is packaging that installs and enables both a system unit and a per-user unit on the same host; neither knows about the other.
Add a per-seat KVM ownership guard (crate::seat_lock): before publishing session addressing into vervain_agent_kvm::session_ctx (the single gate every capture/input backend reads at connect time), each instance takes a non-blocking advisory flock on /run/user//vervain-agent.kvm.lock. Both instances address the same active user session through that path and contend on the same file. The winner publishes the addressing and drives the seat; the loser publishes None, so every backend returns KvmError::NotAvailable and opens no portal session and no input device. First acquirer wins; because systemd starts the root system service at boot before any user logs in, the root service is the de-facto sole KVM provider and the per-user instance yields to it. The lock is an open file description, so the kernel releases it if the holder exits or crashes, and session_watch republishes through the same guard, which moves the lock when the active session switches.
All three publish sites (root startup seed, per-user seed, and the logind supervisor's republish) route through active_session::publish_guarded so the guard applies uniformly.
Document the root cause and the intended single-instance deployment in docs/single-instance-deployment.md: install exactly one unit per host (root system service on a managed host, per-user unit on an unprivileged host), with the seat lock as the in-process safety net against a stray second launch.
#VA-108