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".
Knowing session would be handy for session-aware tools to work on current session without specifying it, like for `loginctl lock-session`, loginctl terminate-session ''`, or any potential generalized "logout" apps.
Also terminating a session with `systemctl --user start --wait wayland-wm@${WM}.service` (or killing the process) does not result in stopping of the compositor.
The compositor, its unit and all the dependencies continue running in background, but the tty is now owned by getty and there is no way to get back to the graphical session. The only way then is to stop the compositor unit manually and start a new one.
For example I have to modify wlogout logout command to `systemctl
--user stop wayland-wm@*.service`,
because:
The default `loginctl terminate-user $USER` would nuke all my
sessions
Using arguably the most logical `loginctl terminate-session ''`
does not work (`Failed to issue method call: Caller does not
belong to any known session.`).
Using `loginctl terminate-session $XDG_SESSION_ID` requires this
var exported to systemd environment.
And in general `terminate-session` will result in inaccessible
compositor as described above. A heavier alternative to --wait
would solve part of those problem, something like --bind that
would not only make systemctl wait for unit to finish, but stop it
if systemctl is terminated.
