Re: User wayland session, conceptual questions

[Mantas Mikulėnas <grawity@xxxxxxxxx>]

On Fri, Feb 10, 2023, 00:11 Vladimir Kudrya <vladimir-csp@xxxxxxxxx> 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@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.