3 Commits

Include renames

Author	SHA1	Message	Date
jschoubben	1a021052fe	Drop the never-ran reading: a start timestamp of 0 does not mean a one-shot never ran (issue 1126) ... Review round 1 measured it on systemd 262.1: a finished one-shot nothing references is unloaded, and loaded again it reads inactive, ExecMainStatus=0 and a start timestamp of 0, as one that never ran does. The previous commit's rule read such a unit stopped, so a one-shot declared running would be started, read stopped and fail on every apply, and the hold, the take-over and the giving back would judge it wrongly. ServiceState keeps main's reading. ServiceAtRest and declaredState stay: they alone satisfy a stopped declaration for a one-shot at rest, which is the kernel cleanup's case. A one-shot declared running that must be seen to have run lingers (RemainAfterExit) or is enabled at boot. Unit tests: the arch table has 5 rows, the apply test 1; 1262 in all.	2026-10-28 14:29:16 +01:00
jschoubben	cf738cdb90	Read a one-shot that never ran as stopped, and one at rest as stopped to a stopped declaration (issue 1126) ... The kernel module's boot-time cleanup, linux-modules-cleanup.service (Type=oneshot, declared stopped and enabled at boot), failed its delivery on ace with 'was asked to be stopped and is running': ServiceState read every inactive one-shot with ExecMainStatus=0 as running, and systemd says 0 for one that never ran too. Stopping an inactive unit changes nothing, so the read back said running again; after a boot that ran it, the same declaration would fail every apply. ServiceState now reads ExecMainStartTimestampMonotonic: 0 means never ran, read as stopped (a package's one-shot declared running is then started, and the hold no longer counts it as in use). The service apply reads a one-shot at rest as stopped to a declaration that it be stopped (ServiceAtRest), whatever its last run did. Quick fix weighed: declare the cleanup running in the catalogue. Thorough chosen: the reading was wrong for every one-shot, and this is its second fault of the kind (the firewall's was the first). Unit tests: three arch one-shot tests merged into one table (7 rows), one apply test (2 rows); 1263 to 1262.	2026-10-28 14:29:16 +01:00
jschoubben	e7f94e0402	A one-shot service that finished is not stopped, and a container is what it reads ... 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.	2026-09-14 16:51:57 +02:00