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