Support a per-host service and data dir when $HOME is shared across machines

[greefea]

Problem

On HPC clusters and other NFS-home setups, several machines share one $HOME (e.g. a login node and a compute node). #23878 and #29872 made the "one unit serves one T3 home" rule safe on a single machine; this request is about the case where one $HOME belongs to several machines, so the one unit is shared by all of them.

• t3 up always writes ~/.config/systemd/user/t3code.service with one T3CODE_HOME. Every host's systemd --user reads that same file, so every host runs a launcher against the same data dir.
• The first host takes server-owner.sqlite. On every other host:
  • t3 serve fails with ServerAlreadyRunningError.
  • t3 pair fails with NoRunningServerError, because server-runtime.json describes a process on another machine.
  • t3 up reports the service as running, but that's only the local launcher ("Another T3 Code server owns this T3 home"), which can't start a server.
• t3 up --base-dir ~/.t3-hostB on the second host is refused with BootServiceOtherBaseDirError. The error suggests t3 service uninstall --base-dir ~/.t3, but that removes the unit for every host, including the one that works.
• Giving each host its own --base-dir through t3 up can't work either: whichever host runs t3 up last rewrites the shared unit, and the other host follows it on its next restart (the t3 service install silently rebinds an existing service to a different base dir, orphaning its data #23858 failure, across machines).

Expected

Each host can run its own background service with its own data dir and T3 Connect environment, managed with the normal t3 up / t3 connect / t3 update / t3 service * commands.

Possible approaches (any one would do)

1. Hostname-aware unit: resolve the data dir per host inside the unit, e.g. EnvironmentFile=-%h/.config/t3code/hosts/%l.env overriding T3CODE_HOME, plus a CLI option that writes that file and sets up the new home's runtime/ for the current host. BootServiceOtherBaseDirError and t3 status would compare against the effective per-host home instead of the unit file's Environment= line.
2. Per-host unit name: let the unit name carry a suffix (t3code@<host>.service, or a --service-name flag), with ConditionHost= so each unit starts only on its own machine.
3. Detection: at minimum, detect when the owner lock is held by a process on a different machine (owner metadata recording the hostname would show this). Report it clearly instead of "no running server", and don't suggest an uninstall that would break the other host.

Current workaround (works on both hosts)

1. Add a drop-in at ~/.config/systemd/user/t3code.service.d/per-host.conf (drop-ins survive t3 rewriting the unit):

   [Service]
   Environment=T3CODE_HOME=%h/.t3
   EnvironmentFile=-%h/.config/t3code-hosts/%l.env

2. On the second host, create ~/.config/t3code-hosts/<short-hostname>.env containing T3CODE_HOME=/home/<user>/.t3-<host>.
3. Set up the second home's runtime/. The launcher reads <home>/runtime/service-state.json and runs <home>/runtime/versions/<activeVersion>/; only t3 service install creates these, and it refuses a second home:

   mkdir -p ~/.t3-<host>/runtime/versions
   cp -al ~/.t3/runtime/versions/0.1.8 ~/.t3-<host>/runtime/versions/
   printf '{"protocol":3,"activeVersion":"0.1.8"}\n' > ~/.t3-<host>/runtime/service-state.json

   Without this the launcher exits with ENOENT: ... runtime/service-state.json.
4. On the second host, export T3CODE_HOME=~/.t3-<host>, run t3 connect link, then systemctl --user daemon-reload && systemctl --user restart t3code. t3 connect status then reports "Tunnel connected", and t3 pair works.

Remaining rough edges:

• On the second host, t3 up, t3 service restart and t3 status still refuse or report "installed for another T3 home", because they read T3CODE_HOME from the unit file instead of the effective environment. The service has to be managed with systemctl --user.
• The second host can't use t3 update. After the first host updates, the second host's runtime/ has to be set up again by hand for the new version.
• Both hosts' service logs go to the first host's ~/.t3/userdata/logs/boot-service.log, because StandardOutput= in the unit is a fixed path.

Related

#23878 and #29872 (merged: service commands refuse or leave alone a unit serving another T3 home, which is correct for one machine but, on a shared $HOME, blocks a second host and still lets uninstall --base-dir ~/.t3 remove the unit for both), #29848, #23858, #17490 (unit pinned to one runtime), #2999 (closed multi-instance proposal, single machine only)

Environment

t3 0.1.8, Rocky Linux 9, systemd 252, NFS-shared $HOME, lingering enabled