[systemd-devel] User wayland session, conceptual questions

[Mantas Mikulėnas]

On Fri, Feb 10, 2023, 00:11 Vladimir Kudrya <vladimir-csp at yandex.ru> wrote:

> Hello everyone!
>
> As an experiment I wrote a session manager for standalone wayland
> compositors that utilizes systemd user-level daemon features for graphical
> sessions: https://github.com/Vladimir-csp/uwsm
>
> It can either manage targets by itself and launch wayland session in a
> scope, or launch wayland session as a service and fully rely on
> dependencies.
>
> I have some conceptual questions regarding where various user processes
> really should end up in.
>
> user-N.slice
>   session-N.scope
>     stuff launched in login console
>     Xserver lanuched via startx goes here
>     so are apps launched inside X session
>   user at N.service
>     app.slice
>       native in-session services
>       XDG autostart derived services
>       currently uwsm-managed units end up here
>       so are all apps launched inside uwsm-managed wayland sessions.
>     init.scope
>       systemd internal stuff
>     session.slice
>       per-user important services
>
> Unlike the case of X session launched via startx, session-N.scope now only
> has "login" and "systemctl --user start --wait wayland-wm@${WM}.service"
> processes. Seems kinda barren. Intuitively I would expect to have apps
> launched in my session here.
>
Yes, but in systemd, slowly the focus has shifted away from distinct
sessions towards users (e.g. compare D-Bus session bus in /tmp/<random> vs
user bus in /run/<UID>) and towards only supporting one graphical login per
user.

Both GNOME and KDE already work this way – the "session" only has a holding
process, everything else runs under systemd.

The whole graphical session (wayland-wm@${WM}.service or
> wayland-wm-${WM}.scope depending on uwsm mode of operation) and apps live
> in the app.slice. Which seems to be in accordance to app.slice description
> in systemd.special manual.
>
> But those apps know which session they sort-of belong to because
> $XDG_SESSION_ID (along with some other vars) is exported by uwsm to systemd
> activation environment during startup. It seems kinda hacky, but works.
>
They don't really *need* to know it. It rarely ever matters, as most things
are user-wide now; e.g. polkit has long ago been adjusted to consider "any
session of this user is active" instead of "this specific session is
active".

Also systemd.special manual recommends putting display servers into
> session.slice. But in case of a wayland compositor it is impossible to
> separate it from the apps, because the compositor handles keyboard
> shortcuts (which launch apps or launchers which launch apps). Is this
> recommendation even feasible for wayland?
>
Yes; the compositor can use systemd D-Bus API to launch apps in their own
.scopes underneath app.slice (or transient .services), as e.g. GNOME Shell
already does.

(For a different use of the same API, see also how GNOME Terminal – or
libvte, I guess – launches each terminal tab in its own .scope. You can
forkbomb a single tab without significantly affecting the rest of the
system.)

If the task at hand is to launch a wayland session after login, propely
> utilizing graphical-session-pre.target, graphical-session.target,
> xdg-desktop-autostart.target, am I going in the right direction? Which of
> the two startup modes I implemented is more correct? Any advice would be
> welcome. Thank you.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20230210/98c932a5/attachment.htm>