installer: fix empty -email flag breaking the default install, and make re-runs safe

[TeoSlayer]

Two launch-blocking defects found in container testing.

F1 — malformed systemd unit on the default install (CRITICAL)

The advertised non-interactive curl -fsSL https://pilotprotocol.network/install.sh | sh sets no email, and the unit rendered -email with an empty value:

  -identity /home/<user>/.pilot/identity.json \
  -email  \
  -encrypt

Go's flag parser consumed the next flag (-encrypt) as the email value, so the daemon failed validation every 5s forever — daemon start: invalid email: email address must contain @ → pilot-daemon.service: Failed with result 'exit-code'. The node never registered, and -encrypt was silently swallowed.

Fix: every optional argument is emitted as a complete flag+value pair or not at all. Omitting -email is the well-defined path — the daemon falls back to ~/.pilot/account.json and, failing that, synthesises <fingerprint>@nodes.pilotprotocol.network, exactly as the installer header already documents. The macOS LaunchAgent plist had the same empty-argument shape and is fixed identically. -hostname / -public were already guarded against this.

F2 — re-running the installer failed on a systemd host

pilot-updater is now auto-enabled and RUNNING after install, so cp over its live binary failed with ETXTBSY ("Text file busy"), aborting mid-install under set -e with binaries partially replaced.

Fix: binaries install via a same-directory temp file + rename(2) — immune to ETXTBSY, and it cannot leave a truncated binary at the real path. Managed services are stopped before the swap and restarted after, so the new image is actually picked up. The whole staged payload is resolved and validated before anything is replaced, so an incomplete download leaves the existing install untouched.

Coupled fix — re-run is now a real repair path

The update path used to exit 0 before the unit was ever rewritten, so re-running could never repair a host installed by a buggy installer — which is the only remedy available to every existing install (historically pinned at its install-time version).

Unit/plist generation, service restart and PATH setup now run on both paths; only the first-run onboarding text is skipped on upgrade. config.json and auto-update.json stay fresh-install-only so a re-run never clobbers operator settings, and -hostname / -public already baked into an existing unit/plist are preserved when the matching env var is not supplied.

A crashlooping unit reports activating/failed rather than active, so the restart set includes an enabled-but-failed unit — precisely the state the -email bug produced.

Container proof

ubuntu:24.04 + systemd as PID 1, arm64, non-root user with passwordless sudo:

Assertion	Result
Both defects reproduced against current main	-email \ + invalid email crashloop; re-run REAL_EXIT=1 on ETXTBSY
Fresh non-interactive install, no email → no dangling -email	unit ends -encrypt, zero -email occurrences
…daemon starts, stays up (3 checks over ~50s)	active, NRestarts=0, stable MainPID
…and registers	daemon registered node_id=251638 addr=0:0000.0003.D6F6, synthetic email
PILOT_EMAIL set → renders correctly and works	-encrypt -email teodor+ctest@vulturelabs.io, active, NRestarts=0, registered
Re-run installer over running services (5×)	exit 0 every time, binaries swapped, daemon + updater active after
systemctl is-enabled pilot-updater	enabled and active throughout
Broken install repaired by one re-run	unit fixed, -hostname pilot-ctest-repair preserved, daemon active + registered
bash -n / sh -n / shellcheck -s sh	all clean

All test nodes (251638–251642) were pilotctl deregister'd and confirmed absent — pilotctl lookup returns node not found, pilotctl find pilot-ctest-repair returns hostname not found.

🤖 Generated with Claude Code