lhumina_code/home
23
0
Fork 0
Code Issues 6 Pull requests Projects Releases Packages Wiki Activity Actions

[nu-demo] service_livekit has no redis preflight — install fails on fresh VM #133

New issue
Closed
opened 2026-04-23 23:15:30 +00:00 by mik-tf · 1 comment
mik-tf commented 2026-04-23 23:15:30 +00:00
Owner
Copy link

Symptom

service_livekit start errors with:

Command 'redis-cli' not found

on a fresh VM. Livekit never comes up because its preflight checks redis via redis-cli ping.

Root cause

service_livekit.nu's preflight assumes redis-cli exists and that a local redis-server is running. Neither is installed by default; the installers/installers.nu base set does not include redis-server / redis-tools (see also companion issue #128 on missing apt deps).

Demo workaround (applied 2026-04-23)

apt-get install -y redis-server redis-tools
redis-server --daemonize yes
service_livekit start

Proper fix

service_livekit.nu's install step should:

  1. pkg_ensure redis-server redis-tools so the binaries exist.
  2. Start redis as a managed daemon (systemd/zinit/hero_proc action), not a bare --daemonize yes — so it restarts on reboot and is observable by the orchestrator.

Filed 2026-04-23 nu-shell demo bring-up. Signed-off-by: mik-tf

## Symptom `service_livekit start` errors with: ``` Command 'redis-cli' not found ``` on a fresh VM. Livekit never comes up because its preflight checks redis via `redis-cli` ping. ## Root cause `service_livekit.nu`'s preflight assumes `redis-cli` exists and that a local `redis-server` is running. Neither is installed by default; the `installers/installers.nu` base set does not include `redis-server` / `redis-tools` (see also companion issue #128 on missing apt deps). ## Demo workaround (applied 2026-04-23) ``` apt-get install -y redis-server redis-tools redis-server --daemonize yes service_livekit start ``` ## Proper fix `service_livekit.nu`'s install step should: 1. `pkg_ensure redis-server redis-tools` so the binaries exist. 2. Start redis as a managed daemon (systemd/zinit/hero_proc action), not a bare `--daemonize yes` — so it restarts on reboot and is observable by the orchestrator. Filed 2026-04-23 nu-shell demo bring-up. Signed-off-by: mik-tf
mik-tf commented 2026-04-27 03:19:52 +00:00
Author
Owner
Copy link

Fixed in hero_skills commit 4927b3d on development.

Two coupled changes implementing both halves of the issue's proper fix:

1. Binary install — installers/installers.nu install_base:

pkg_ensure_dev "redis-server"
pkg_ensure "redis-cli"     --pkg "redis-tools"

apt's redis-server postinst auto-starts the systemd unit on systemd hosts, so most installs reach service_livekit start with redis already running. On non-systemd hosts the binary is still present for the daemonize fallback below.

2. Proactive start — services/service_livekit.nu svx_ensure_redis:

Replaces the soft warn-only svx_check_redis with a 3-step ensure:

  1. Already responding → done.
  2. Try sudo systemctl start redis-server → done on systemd hosts.
  3. Fall back to sudo redis-server --daemonize yes for non-systemd hosts (TF Grid VMs).
  4. If all three fail, warn — operators running redis on a non-default addr/port via their own config aren't blocked.

The bare-daemonize path is explicitly the fallback (with a note that restart-on-reboot won't be automatic), not the canonical path. The issue body called this out specifically ("not a bare --daemonize yes"); the canonical answer would be to register redis as a hero_proc action so it's restartable + observable like every other hero service. Filed as future work in a later iteration of this meta plan if the daemonize path proves insufficient in practice — for now redis-server from apt brings its own systemd unit on every Ubuntu we've encountered, so the daemonize fallback is rarely exercised.

Verification: nu -c 'source <file>' parses cleanly for both modified modules.

Meta-tracker: home#193.

Signed-off-by: mik-tf

Fixed in hero_skills commit `4927b3d` on `development`. Two coupled changes implementing both halves of the issue's proper fix: **1. Binary install — `installers/installers.nu` `install_base`:** ```nushell pkg_ensure_dev "redis-server" pkg_ensure "redis-cli" --pkg "redis-tools" ``` apt's `redis-server` postinst auto-starts the systemd unit on systemd hosts, so most installs reach `service_livekit start` with redis already running. On non-systemd hosts the binary is still present for the daemonize fallback below. **2. Proactive start — `services/service_livekit.nu` `svx_ensure_redis`:** Replaces the soft warn-only `svx_check_redis` with a 3-step ensure: 1. Already responding → done. 2. Try `sudo systemctl start redis-server` → done on systemd hosts. 3. Fall back to `sudo redis-server --daemonize yes` for non-systemd hosts (TF Grid VMs). 4. If all three fail, warn — operators running redis on a non-default addr/port via their own config aren't blocked. The bare-daemonize path is explicitly the **fallback** (with a note that restart-on-reboot won't be automatic), not the canonical path. The issue body called this out specifically (_"not a bare `--daemonize yes`"_); the canonical answer would be to register redis as a hero_proc action so it's restartable + observable like every other hero service. Filed as future work in a later iteration of this meta plan if the daemonize path proves insufficient in practice — for now `redis-server` from apt brings its own systemd unit on every Ubuntu we've encountered, so the daemonize fallback is rarely exercised. **Verification:** `nu -c 'source <file>'` parses cleanly for both modified modules. Meta-tracker: home#193. Signed-off-by: mik-tf
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
development
main
No results found.
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
lhumina_code/home#133
No description provided.