HydraIssues

CORRECTED 2026-09-15 after inspecting msi1060 directly. The original filing claimed hydrabody referenced a unit nothing creates. That was wrong. The real risk is narrower and is a port collision, not a missing unit.

WHAT IS ACTUALLY ON msi1060 (spicy-cactus-76, node-d71b197c, Omarchy, district bxl1-test):

• sunshine 2026.516.143833-4.1 is installed, and its packaged user unit app-dev.lizardbyte.app.Sunshine.service exists but is NOT enabled.

• hydra-sunshine.service EXISTS, is enabled into graphical-session.target.wants, and is active. It is a hand-written user unit (no package owns it) that runs the PACKAGED binary against a Hydra-owned config:

  ExecStart=/usr/bin/sunshine /var/lib/hydra/sunshine/config/sunshine.conf
  ConditionPathExists=/var/lib/hydra/sunshine/config/sunshine.conf
  WorkingDirectory=/var/lib/hydra/sunshine/config

• The user has NO personal ~/.config/sunshine/sunshine.conf.

• The Omarchy bar plugin is NOT installed on this machine.

• The Linux launch path from PR #1 is demonstrably working: a transient unit hydra-template-flat-20260915.service is running /opt/hydra/experiences/hydraunrealtemplate/run.sh.

So hydrabody's hardcoded hydra-sunshine.service is satisfied here, and the separation is deliberate and reasonable: use the distro binary, but run it under a Hydra-owned unit and config in /var/lib/hydra/sunshine, away from the user's own Sunshine settings. Not a bug.

THE REAL ISSUE, LATENT BUT GENUINE

The plugin's scripts/setup-body.sh writes ~/.config/sunshine/sunshine.conf and enables the PACKAGED unit. Neither config sets a port, so both default to 47989. Install the plugin on a machine that is already a Hydra body, run its body setup, and you get two Sunshine processes contending for the same ports and the same display. The failure would look like a flaky or unreachable body rather than an obvious clash.

Nothing has gone wrong yet only because the two have never been co-installed. msi1060 is where they will first meet.

WHAT TO DECIDE

(a) The plugin's body setup detects an existing hydra-sunshine.service and refuses, pointing the operator at the managed path. Cheapest, and keeps the two honest about ownership.
(b) hydrabody's config sets a non-default port so the two can coexist, and the head side learns the port.
(c) Declare them mutually exclusive per machine and document it in both READMEs.

Recommend (a), with the wording in the plugin README that a Hydra-managed body is already a body.

STILL WORTH RECORDING (unchanged from the original filing): the plugin already implements avahi Sunshine discovery, PIN pairing, app listing and stream start/stop on Omarchy. #734 should reuse that rather than rebuild head-side discovery. The plugin covers the FLAT lane; WiVRn/PyroWave (#388) is the XR lane.

RESOLVED 2026-09-15 in the plugin, option (a): omarchy-hydra-experiencenet master eb249c9.

• The body probe reports body=managed when ~/.config/systemd/user/hydra-sunshine.service exists. The check runs BEFORE the pgrep that would otherwise read a cluster-managed Sunshine as the plugin's own.
• The Body view says the machine is already a Hydra ExperienceNet body, and offers neither setup nor stop. Stopping a unit the cluster owns only makes hydrabody restart it. Sunshine settings stays available.
• setup-body.sh refuses on such a machine and changes nothing, naming the unit and offering --force as the deliberate override.
• Head view discovery, pairing and streaming are untouched.
• Covered by a new section in docs/testbooks/body-mode-e2e.md; step 8 counts sunshine processes rather than trusting the message. Model tests extended for the managed state and passing.

Not yet released: the plugin is at v0.5.8 and this is on master. Tag when you want it out.

hydrabody was left alone deliberately: its unit and config separation under /var/lib/hydra is the more careful arrangement of the two, and the collision is only ever created by the standalone path.