Most units contained in this repo do not really depict a well-formed & intended
use-case for systemd --user. In fact, most of the trivial well-formed user/
units (like gpg-agent.service
and friends, pulseaudio.service etc.)
already got included in their respective upstream projects and were
correspondingly dropped from here.
Instead, this repo is an (unmaintained) attempt to have a completely
systemd --user-driven user session. I'll try to explain what is going on,
esp. since this repo got mentioned in a certain lecture series on GNU/Linux
userspace.
As far as systemd is concerned, processes run in three different "scopes"
("scopes" in abstract sense, not related to .scope units, although they do
reflect this hierarchy to some degree):
- system-wide services,
- per-user services, and
- user sessions.
The system-wide services are things directly launched by the PID 1, in a clean
environment and "system-wide lifetime". These processes are not bound to any
user or any login session and cannot be meaningfully made so because they are in
an "enclosing lifetime". For example, you cannot make a system-wide service
launching some X program for your graphical login session, because at the moment
system services are started there are no user logins and no $DISPLAY to talk
to.
The per-user services are launched by systemd --user instances which are
started once per user, either directly preceding their first login or as part
of general boot sequence if "lingering" (loginctl enable-linger) is enabled
for a user. If "lingering" is not enabled, the systemd --user instance is
started by PAM (pam_systemd.so) as part of user login.
Regardless of this, systemd --user proceeds to activate its default.target.
Moreover, PAM will not return control to the calling application until the
per-user basic.target is reached.