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:
mwiegand 2026-05-15 01:59:56 +02:00
parent 62cf6cdd56
commit a450491a90
No known key found for this signature in database

View file

@ -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. inherited "we have 2 users" as a constraint, not as a design choice.
This doc fixes that. 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) ## Current state (2 users)
User → what runs as it: User → what runs as it: