A one-shot service that finished is not stopped, and a container is what it reads #12

2026-09-14T15:16:02Z

jschoubben commented

2026-09-14 15:16:02 +00:00

Two faults that both reported success while being wrong, found while proving the firewall module actually delivers rather than assuming it.

The firewall module has never worked, on any machine, ever. Its unit loads a rule set and exits — which is what that kind of unit does — so it is reported inactive the instant it succeeds. The host read that as "stopped", started it again, read back "stopped" again, and declared the machine as not doing what it was told. On every apply, for ever, with the rules correctly in place the whole time. That is why the four-machine bed was red, and it would have made the anchor look broken too.

A one-shot that ran and exited zero now reads as satisfied. One that exited non-zero still reads as stopped, or the host would report success for work that did not happen — the opposite mistake and the worse one. A one-shot that deliberately lingers is unaffected: it says so, and its active state is the answer.

And a container took its identity from its own fields, not from the files it reads. A file written in an earlier apply — or written before the container named it as a dependency — left a process holding a credential the mesh had already replaced, with every check passing: container up, spec matched, machine reported success (novox/hq issue 045). The existing restart-on mechanism is a tripwire that fires during the apply where a file moves and never again.

What a container reads is now part of what it is, so the comparison is standing rather than edge-triggered. A container whose configuration has since been rewritten compares different and is replaced.

Verified on a live mesh: the firewall module now applies, loads its rules, and the machine reports itself as doing what it was told.

Two faults that both reported success while being wrong, found while proving the firewall module actually delivers rather than assuming it. **The firewall module has never worked, on any machine, ever.** Its unit loads a rule set and exits — which is what that kind of unit does — so it is reported inactive the instant it succeeds. The host read that as "stopped", started it again, read back "stopped" again, and declared the machine as not doing what it was told. On every apply, for ever, with the rules correctly in place the whole time. That is why the four-machine bed was red, and it would have made the anchor look broken too. A one-shot that ran and exited zero now reads as satisfied. One that exited non-zero still reads as stopped, or the host would report success for work that did not happen — the opposite mistake and the worse one. A one-shot that deliberately lingers is unaffected: it says so, and its active state is the answer. **And a container took its identity from its own fields, not from the files it reads.** A file written in an earlier apply — or written before the container named it as a dependency — left a process holding a credential the mesh had already replaced, with every check passing: container up, spec matched, machine reported success (novox/hq issue 045). The existing restart-on mechanism is a tripwire that fires during the apply where a file moves and never again. What a container reads is now part of what it is, so the comparison is standing rather than edge-triggered. A container whose configuration has since been rewritten compares different and is replaced. Verified on a live mesh: the firewall module now applies, loads its rules, and the machine reports itself as doing what it was told.

jschoubben added 1 commit 2026-09-14 15:16:03 +00:00

A one-shot service that finished is not stopped, and a container is what it reads e7f94e0402

Two faults that both reported success while being wrong, found while proving
the firewall module actually delivers.

A unit whose job is to apply something and exit — load a rule set, set a
sysctl — is inactive the instant it succeeds. Reading that as stopped made it
permanently unsatisfiable: the host started it, it worked, the host read back
stopped and reported the machine as not doing what it was told, on every apply,
for ever, with the rules correctly in place the whole time. That is what the
firewall has been doing on every machine it was assigned to, and why the
four-machine bed was red.

And a container took its identity from its own fields, not from the files it
reads. A file written in an earlier apply — or before the container declared it
as a dependency — left a process holding a credential the mesh had already
replaced, with everything reporting success (novox/hq 04-ISSUES/045). What a
container reads is now part of what it is, so the comparison is a standing one
rather than a tripwire that fires during one apply and never again.

jschoubben merged commit 200c6c127f into main

2026-09-14 15:16:14 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: novox/mesh-host#12