ADR 0117 accepted; a manager that cannot reload takes the setting at its next start (dhcpcd, measured)

2026-09-26 23:58:48 +02:00
parent 504adef221
commit 0e066473b3
2 changed files with 8 additions and 4 deletions
@@ -1,6 +1,6 @@
 ---
 topic: what runs on it
-status: proposed
+status: accepted
 date: 2026-09-26
 deciders: jochen
 reconstructed: false
@@ -80,8 +80,12 @@ other:
 - each as a drop-in beside the manager's main file where the manager reads one, and written
  *into* a shared file otherwise ([ADR 0102](0102-the-mesh-writes-into-a-shared-file-never-over-it.md));
 - the service **reloaded** when a drop-in changes, never restarted — a restart drops the link,
-  and the link is the mesh's own channel to the machine. Whether each manager applies these
-  settings on a reload is measured in the lab before its module is written, not assumed.
+  and the link is the mesh's own channel to the machine. **A manager that cannot reload is not
+  restarted instead:** its setting takes effect at the manager's next start. Measured on the
+  adopted machines: NetworkManager (1.58) and systemd-networkd (systemd 261) both report
+  `CanReload=yes`; dhcpcd (10.3) reports `CanReload=no`, so its module declares no trigger at
+  all. Whether each setting is actually *applied* by a reload is confirmed on a machine before
+  the module is taken there, not assumed.

 **What a holder never declares:** a link, an address, a route, a connection profile, a
 wireless network or its credentials. Those are the operator's, in the sense of