spec(uid-split): note these are system units, not user units
Explicit clarification so the next agent doesn't go looking for user-unit friction. left4me-server@.service and left4me-web.service are system units that drop to User=left4me; the 3-user split is a literal one-line edit per unit. No lingering, no pam_systemd, no per-user systemd instance bootstrap. The privileged ExecStartPre/ExecStopPost steps stay root via the + prefix. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
This commit is contained in:
parent
62cf6cdd56
commit
a450491a90
1 changed files with 18 additions and 0 deletions
|
|
@ -37,6 +37,24 @@ The question never got a structured answer because each plan
|
|||
inherited "we have 2 users" as a constraint, not as a design choice.
|
||||
This doc fixes that.
|
||||
|
||||
## Note: these are system units, not user units
|
||||
|
||||
Both `left4me-server@.service` and `left4me-web.service` are
|
||||
**system units** at `/usr/local/lib/systemd/system/`, started by
|
||||
PID 1, that drop to the unprivileged uid via `User=left4me`
|
||||
`Group=left4me` after their `+`-prefixed ExecStartPre runs as root.
|
||||
They are **not** user units (no `systemctl --user`, no per-user
|
||||
systemd instance, no lingering required).
|
||||
|
||||
This makes the user-split refactor much simpler than it would be
|
||||
otherwise. Changing `User=`/`Group=` in the unit is a literal
|
||||
one-line edit per unit. None of the typical user-unit friction
|
||||
applies — no lingering setup, no `pam_systemd` dependency, no
|
||||
"how does the user instance get bootstrapped on boot," no socket
|
||||
activation gymnastics. The privileged ExecStartPre/ExecStopPost
|
||||
steps continue to run as root via the `+` prefix regardless of
|
||||
what `User=` is set to.
|
||||
|
||||
## Current state (2 users)
|
||||
|
||||
User → what runs as it:
|
||||
|
|
|
|||
Loading…
Reference in a new issue