Repository navigation
nixos/pm-apps: remove pm-kaneo + pm-postgres oci-containers (compose is their manager) - #3847
Conversation
Kaneo and its PostgreSQL are compose-managed by the pm-stack module (pm-kaneo.service + self-heal timer running ~/pm-stack/deploy.sh) and have been throughout: the #1752 oci migration for them never completed, and the duplicate declarations actively fought the live stack — docker-pm-kaneo failed at every activation (port 5173 held by the compose container) and two postmasters ran against the one pm-stack_postgres_data volume from 2026-11-01 00:35 until the oci postmaster (zero client connections; compose serves Kaneo) was stopped later that day. Grist, Pad and ready-for-agent are unaffected and stay declared here. Interim laptop state (already applied): docker-pm-kaneo and docker-pm-postgres stopped + reset-failed; Kaneo verified up via compose the whole time. This PR makes the removal declarative at the next switch.
|
Warning Review limit reachedYou've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Next included review available in 54 minutes. View limit details
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
|
Incident record: #3849 (two postmasters on the PM data volume + this unit's start-limit loop; interim laptop actions and the reboot caveat are documented there). This PR is the durable fix referenced in that issue. |
What
Removes the
pm-kaneoandpm-postgresoci-container declarations fromnixos/services/pm-apps. Kaneo and its PostgreSQL are — and throughout the incident remained — managed by the pm-stack module's compose path (pm-kaneo.service+pm-kaneo.timerrunning~/pm-stack/deploy.sh). Grist, Pad, and ready-for-agent are untouched.Why (2026-11-01 incident)
The code#1752 migration declared oci-containers for Kaneo/PostgreSQL but its activation never completed: the pm-stack compose units stayed enabled, and the compose self-heal timer resurrected the compose stack at 2026-11-01 00:35. From then:
docker-pm-kaneo.servicefailed at every activation —Bind for 127.0.0.1:5173 failed: port is already allocated(the compose container holds it), restart-looping to start-limit-hit.pm-stack_postgres_datavolume (the oci postmaster, up since 2026-10-30, and the compose postmaster from 00:35). Verified live: both accepting connections on the same PGDATA; the oci postmaster had zero client connections while the compose postmaster held Kaneo's pool (4 backends).Interim state (already applied to the laptop today)
docker-pm-postgres.servicestopped — the idle second postmaster is gone; the compose postmaster is now the only one on the data volume.docker-pm-kaneo.servicestopped + both unitsreset-failed.GET 127.0.0.1:5173→ 200 throughout./etc/systemd/systemis read-only on this host, so the units could not be disabled outside a switch — if the laptop reboots before this PR lands via a switch, both units will start again (kaneo failing, postgres double-running). Landing this with the pending fold switch removes them declaratively.Decision left open
Completing the #1752 migration for Kaneo/PostgreSQL instead would mean disabling the pm-stack compose service+timer and planning the cutover. This PR takes the other branch — compose is the single declared manager — because that is what has actually been running the PM stack. The module header records the history either way.
Need help on this PR? Tag
@codesmith-botwith what you need.