3 Commits

Include renames

Author	SHA1	Message	Date
jschoubben	a9b02bc676	node-tools: keep the stopping-runtime test under a second, and start no first bundle once stopping ... The test watched two seconds per row; a 10 ms restart pause and a 250 ms window prove the same. launch.Start itself now refuses while the runtime stops, so a reload's first start is held too (issue 1126).	2026-10-28 15:40:39 +01:00
jschoubben	f016c67a72	node-tools: start no bundle again once the runtime itself is stopping (issue 1126) ... The service manager stops node-tools by signalling its whole group, so every bundle gets SIGTERM with it; the launcher took each exit for a fault and started the bundle again, for the 15 s the runtime took to stop. On ace's reboot of 2026-10-28 those restarted bundles dialled the system bus once polkit and the bus had stopped, the bus and polkit came back during the shutdown, nothing stopped them a second time, and the reboot waited 29 minutes on its job timeout. ShutDown, called first on SIGTERM, keeps any bundle from starting again, by a restart or by a call; a running one still answers.	2026-10-28 15:30:12 +01:00
jochen	1eaa1abbe9	Prove a write by compare-and-set loses no update under contention, on a real bus (hq research 042) ... The issues module will hand out numbers through mesh/state.create and update. Two writers incrementing one counter a thousand times each through the module's bus now end at two thousand with every number handed out once; a stale, zero or future revision is refused with the lost-write code and writes nothing; a deleted key can be created again; and the lost-write code reaches a bundle wrapped or not, and no other refusal carries it. Both runtime tests run in the check's bundleless list, so mesh/repo-check runs them. Part of the issue tracker decision, hq research 042.	2026-10-10 12:31:06 +02:00