[systemd-devel] User wayland session, conceptual questions

[Vladimir Kudrya]

On 10/02/2023 12.51, Mantas Mikulėnas wrote:
>
>     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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20230210/ab5085a3/attachment.htm>