Issue 210: the host re-creates the node's runtime on every reconcile, restarting it every ten minutes #317

Merged
mesh-admin merged 2 commits from issues/210-the-host-re-creates-the-runtime-every-cycle into main 2026-10-03 11:20:27 +00:00
Showing only changes of commit 911125148c - Show all commits
@@ -36,13 +36,16 @@ when the machine is as declared; a `process` here never does.
Owner mesh-host, `internal/apply/process.go`. The decision is: the digest of the fetched bundle Owner mesh-host, `internal/apply/process.go`. The decision is: the digest of the fetched bundle
plus the unit text is `want`; when the host's record of what it last wrote equals `want` and no plus the unit text is `want`; when the host's record of what it last wrote equals `want` and no
`restart-on` resource changed, the process is left alone. The unit text is rendered with sorted `restart-on` resource changed, the process is left alone. Two things were ruled out on the laptop:
keys, so `want` is stable. The log says `created` — the word the code uses only when the previous the credential the runtime restarts on, which has not been written since the evening before (the
record is empty (with a record it would say `updated`) — so what fails is the record: for this host would also say `updated`, not `created`, for a restart it owed to another resource); and the
resource the host does not find what it wrote last cycle. Two candidates, to be settled in the unit text, rendered with sorted keys and so stable. What fails is the record. The host's state file
host's tests: the applied-store does not persist or does not key a `process` outcome the way it is holds an entry for `node-tools.runtime` — applied at the last cycle, with **no `wrote` digest at
read back, or the outcome's `wrote` is dropped before it is saved. **Fix direction:** a test that all** — while the sibling entry for the runtime's credential carries its digest. The apply sets the
applies the same `process` declaration twice against a recorded store and asserts the second digest on its outcome on every path that installs the daemon, and the loop that records outcomes
outcome is `unchanged` with no restart. Observed only on the laptop's journal; the other three copies it into the record for every kind; between the two, a `process` outcome arrives with its
machines' host logs are not readable by the operator account over SSH, and the behaviour is the digest empty. **Fix direction:** find where a `process` outcome loses its digest on the way to the
host's, not the machine's. record, and a test that applies the same `process` declaration twice against a recorded store and
asserts the second outcome is `unchanged` with no restart — the test the shape never had. Observed
on the laptop's journal and state; the other three machines' host logs are not readable by the
operator account over SSH, and the behaviour is the host's, not the machine's.