Skip to content
Cockpit0.29.0
A snapshot: read at commit 707a04c7ce8 on 2026-10-18T00:06:01Z by majordomus 0.29.0. Nothing on this page is read again. See it live

I2722

A hub activates a new version under its service manager, checks its health and rolls back by itself

Where it stands

devtask.issue
Readiness
blocked 1 of its dependencies is not DONE
Status
BLOCKED
Can start
not now
Milestone
safe-self-update
Milestone status
ACTIVE
Wave
1
Waiting on
I2720
Holds back
none
Behind it in all
0
Evidence
0 of 2
In the waySubjectDetail
issueI2720I2720 is not DONE

Moves

plan.transition
A move writes the repository: it stamps one field of this issue's record and appends one event to the ledger, and a commit will carry both.
The same moves from a terminal

majordomus plan start I2722

majordomus plan verify I2722

majordomus plan done I2722

What it is

Objective
Make a hub that has installed a newer release restart onto it through its systemd user unit or launchd agent when no session is attached or after a bounded grace, pass a readiness and mesh verify check, and otherwise rename the launcher back, keep serving the previous version and put a rollout failed entry on the board.
Why
ADR 0161. Hubs run unattended (docs/MESH.md, The hubs as services); the launchd agent is the operator's to install and an installer that writes either unit is owed as a typed capability (ADR 0059).
Now
Updating a hub is a fetch, a build and a service restart by hand; the macOS hub is started by hand.
Wanted
A typed capability writes the hub's systemd user unit or launchd agent from the mesh declaration; after self update installs a newer version the hub restarts onto it under the rules above; the previous versioned tree is kept until the health check passes; a failed version is not retried on that node until a newer one is published.
Done when
unknown: the record declares no `completion`
Risk
unknown: the record declares no `risk`

Acceptance

  • A hub with a newer installed version ends serving it, with no session lost that was attached before the grace
  • A version whose readiness or mesh verify fails is rolled back within the grace and the board names node, version and failed check
  • The hub service unit is written by a capability, not by hand
Validation
bin/majordomus plan validateMJ_TEST_JOBS=4 bash test/run.sh <the case this issue adds>
Evidence required
hub_activates_new_version_testhub_rolls_back_failed_version_test
Evidence present
unknown: the record carries no `evidence` entries

Scope

Touches
apps/majordomus-cli/src/meshapps/majordomus-cli/src/capability/builtinapps/majordomus-cli/src/lease.rsshare/installdocs/MESH.mdtest/cases
Not
Checkout servers' hand-off, which I2163 and I2127 carry
Depends on
I2720
Priority
p0
Profile
implementation
Parallel safe
false
Owner
unknown: the record declares no `owner`

The work so far

Branches
none
Merged
none
Commits
0
Trunk
master
Sessions
none
Created
2026-10-14
Updated
2026-10-14
Started
unknown: the record declares no `started_at`
Verified
unknown: the record declares no `verified_at`
Completed
unknown: the record declares no `completed_at`

Synchronisation

Adapter
scripts/github-sync
Repository
unknown: the derived plan's header carries no repository
External issue
unknown: a live GitHub state; this executable makes no network call, so only `scripts/github-sync --check` can answer it
State there
unknown: a live GitHub state; this executable makes no network call, so only `scripts/github-sync --check` can answer it

Findings

Nothing is wrong with these records.