A one-shot at rest satisfies a stopped declaration, so the kernel's boot cleanup applies (issue 1126)

Conversation 1 Commits 2 Files Changed 4

+185 -79

2 Commits

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) mesh/delivery merged: source.main moved to novox/mesh-host@b4fd2cc210bf Details mesh/check being carried to 1a021052fe07 on b4fd2cc210bf \| from 7a2af2376405 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

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)

mesh/delivery merged: source.main moved to novox/mesh-host@b4fd2cc210bf

Details

mesh/check being carried to 1a021052fe07 on b4fd2cc210bf | from 7a2af2376405

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

A one-shot at rest satisfies a stopped declaration, so the kernel's boot cleanup applies (issue 1126) #162