Run the phone as a boot-start systemd service #10

Merged

balint merged 1 commit from feat/systemd-boot-service into main

2026-06-10 06:28:34 +01:00

balint commented

2026-06-07 23:11:29 +01:00

Owner

Until now the phone only ran in the foreground via make run, so a rebooted (or crashed) Pi stayed silent until someone re-ran it by hand. This installs it as a systemd system service so it always comes back.

Why a system service (not systemd --user): the Pis run plain ALSA — no PulseAudio/PipeWire — so the daemon reaches the USB handset with no login/user session, and the existing LED udev rule already grants the deploy user sysfs write access. No root, no linger.

Ordered After/Wants wg-quick@wg0 since peer_host is the overlay IP — Wants not Requires, because the app retries its peer connection and shouldn't fail to start over a briefly-absent tunnel.

The unit is a template rendered per-Pi (user / workdir / uv path) by scripts/pi_service.sh, mirroring the existing pi_install.sh / pi_config.sh flow, and wired up as make service PI=....

Verified on both Pis: installed, enabled, then rebooted both — each came back automatically (active/enabled, wg0 up, peers reconnected over the overlay, LED SOLID).

🤖 Generated with Claude Code

Until now the phone only ran in the foreground via `make run`, so a rebooted (or crashed) Pi stayed silent until someone re-ran it by hand. This installs it as a systemd **system** service so it always comes back. Why a system service (not `systemd --user`): the Pis run plain ALSA — no PulseAudio/PipeWire — so the daemon reaches the USB handset with no login/user session, and the existing LED udev rule already grants the deploy user sysfs write access. No root, no linger. Ordered `After`/`Wants` `wg-quick@wg0` since `peer_host` is the overlay IP — `Wants` not `Requires`, because the app retries its peer connection and shouldn't fail to start over a briefly-absent tunnel. The unit is a template rendered per-Pi (user / workdir / uv path) by `scripts/pi_service.sh`, mirroring the existing `pi_install.sh` / `pi_config.sh` flow, and wired up as `make service PI=...`. **Verified on both Pis:** installed, enabled, then rebooted both — each came back automatically (`active`/`enabled`, `wg0` up, peers reconnected over the overlay, LED SOLID). 🤖 Generated with [Claude Code](https://claude.com/claude-code)

balint added 1 commit

2026-06-07 23:11:29 +01:00

Run the phone as a boot-start systemd service f2a0c81264

Until now the phone only ran in the foreground via `make run`, so a Pi that
rebooted (or a process that crashed) stayed silent until someone re-ran it by
hand. For an appliance that should always be ready to ring, that's the wrong
default.

Install it as a systemd *system* service rather than a `systemd --user` one:
the Pis run plain ALSA with no PulseAudio/PipeWire, so the daemon reaches the
USB handset with no login/user session, and the existing LED udev rule already
grants the deploy user sysfs write access — so no root and no linger are
needed. Order it `After`/`Wants` `wg-quick@wg0` since `peer_host` is the
overlay IP; `Wants` (not `Requires`) because the app retries its peer
connection, so a briefly absent tunnel shouldn't keep the phone from starting.

The unit is a template rendered on each Pi (user / workdir / uv path) by
`pi_service.sh`, mirroring the existing `pi_install.sh` / `pi_config.sh` flow,
and wired up as `make service PI=...`.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>