<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Feb 10, 2023, 00:11 Vladimir Kudrya <<a href="mailto:vladimir-csp@yandex.ru">vladimir-csp@yandex.ru</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<p>Hello everyone!<br>
</p>
<p>As an experiment I wrote a session manager for standalone wayland
compositors that utilizes systemd user-level daemon features for
graphical sessions: <a href="https://github.com/Vladimir-csp/uwsm" target="_blank" rel="noreferrer">https://github.com/Vladimir-csp/uwsm</a></p>
<p>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.<br>
</p>
<p>I have some conceptual questions regarding where various user
processes really should end up in.</p>
<pre>user-N.slice
session-N.scope
stuff launched in login console
Xserver lanuched via startx goes here
so are apps launched inside X session
<a href="mailto:user@N.service" target="_blank" rel="noreferrer">user@N.service</a>
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
</pre>
<p>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.<br></p></div></blockquote></div></div><div dir="auto">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.<br></div><div dir="auto"><br></div><div dir="auto">Both GNOME and KDE already work this way – the "session" only has a holding process, everything else runs under systemd.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><p>
</p>
<p>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.</p>
<p>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.</p></div></blockquote></div></div><div dir="auto">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".</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
<p>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?<br></p></div></blockquote></div></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">(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.)</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><p>
</p>
<p>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.<br>
</p>
</div>
</blockquote></div></div></div>