3 Commits

Include renames

Author	SHA1	Message	Date
jochen	a018ebd1ca	Pass -- before every unit, and give a unit back only when it is exactly as the mesh held it ... Third review of mesh-catalog #147. A unit's name can now come from a setting (a template's instance), so every systemctl call that names a unit passes `--` before it, and a name can never be read as an option. On removal, a unit is started or enabled again only when it is exactly the stopped and disabled the mesh held it to. A masked unit, or one somebody started or enabled since, is left as it is, and the report says why. A restore that fails (the start refused, or the unit not running after it) puts back what this attempt changed and is reported as waiting, so no apply is made fatal by it and the next one tries again. The tests' fake service managers read systemctl's arguments in the shape they were written for (oldShape); internal/system's own test holds the `--`.	2026-10-09 01:54:26 +02:00
jochen	d5c365cb2b	A user unit waits for its account's manager, and lingering is the account's (hq ADR 0177) ... An account's manager runs only while it is logged in or lingers. A user-scoped unit whose manager is not running is now "waiting" rather than failed, its record kept as it was; its removal is never fatal (kept recorded, retried) and an account that is gone is forgotten. Whether the manager runs is asked of user@<uid>.service in the machine's manager: asking the account's own, through --machine, logs it in. The user shape gains `linger`, set with loginctl, read back from logind's record, and given back on removal like the shell. Unit files the mesh writes under ~/.config/systemd/user or /etc/systemd/user make that unit the mesh's, and made, holds and found units are keyed by manager and name, so an account's unit and the machine's of one name are two units. A service moved between managers gives the old one back through the manager it was in. OpenRC refuses both.	2026-10-04 12:41:32 +02:00
jochen	84540e709a	A unit may be user-scoped: applied through the account's own manager (hq ADR 0177) ... A workstation's per-user daemons — a window manager's reload watcher, an audio mask, a memory guard — are units in the operator account's own service manager, and until now had no form the mesh could send (to-be 29). The `service` shape gains `scope` ("system", the default, or "user") and `user` (the account, named ${machine:account} by a module); a user-scoped unit without an account, or a system unit naming one, is refused at parse. The host reaches the account's manager as `systemctl --user --machine=<account>@` from its own process: no environment to forge, no user to switch to. Done on the runner rather than per system, since every system's reading of a unit already goes through systemctl. Apply, reflect-only and removal all go through the same manager, and the applied record carries scope and user so removal gives the unit back to the manager it came from. It answers only while that manager runs — a login, or lingering enabled for the account; declaring lingering is a follow-up. Tests: a user-scoped unit is started and enabled in the account's manager and recorded with its scope; a system unit never sees --user; the validation of scope and user.	2026-10-04 12:31:24 +02:00