Place xdg-desktop-portal-gtk.service in session.slice

[Atemu]

By default, systemd would place it in app.slice which doesn't make sense; that's where apps go, not daemons that are part of the desktop session.

session.slice makes a lot more sense and it's where the other xdg and/or portal services are placed too.

cc @smcv @Vladimir-csp

[Atemu]

For some more context, here's my current systemd user unit hierarchy:

$ $ systemctl --user status | rg '\.slice$|\.service$'
   CGroup: /user.slice/user-1000.slice/[email protected]
           ├─app.slice
           │ ├─app-rofi-easyeffects-19676.service
           │ ├─app-rofi-firefox\x20\x2d\x2dname\x20firefox-24101.service
           │ ├─app-rofi-signal\x2ddesktop\x20\x2d\x2dno\x2dsandbox-12745.service
           │ ├─dconf.service
           │ ├─dunst.service
           │ ├─emacs.service
           │ ├─emacsclient-26056.service
           │ ├─foot-12775.service
           │ ├─foot-24573.service
           │ ├─foot-2565.service
           │ ├─foot-29533.service
           │ └─xdg-desktop-portal-gtk.service
           ├─background.slice
           │ └─[email protected]
           └─session.slice
             ├─dbus.service
             ├─hypridle-power.service
             ├─hypridle.service
             ├─pipewire-pulse.service
             ├─pipewire.service
             ├─[email protected]
             ├─wireplumber.service
             ├─xdg-desktop-portal-hyprland.service
             ├─xdg-desktop-portal.service
             ├─xdg-document-portal.service
             └─xdg-permission-store.service

As you can clearly see, xdg-desktop-portal-gtk.service is quite out of place here.

[smcv]

We need to be a bit careful about this: it isn't completely obvious that it's 100% correct to do this.

One possible unintended side-effect of doing this is that if x-d-p-gtk launches an application - for example a web browser like Firefox or Chromium to implement the OpenURI interface, or a viewer like Evince or Xpdf to implement the OpenFile interface - then the web browser or viewer could end up also being in session.slice, which we probably don't want.

Is there a functional reason (like perhaps resource management) why x-d-p-gtk needs to be in session.slice, or is your reasoning just "this looks wrong"?

[Vladimir-csp]

I haven't even noticed that x-d-p-gtk goes to app.slice, all other portals are in session.slice. It supposedly gives more priority and responsivenes.

If it needs to launch an application, it probably should launch it in its own unit anyway, otherwise xdg-desktop-portal-gtk.service would just accumulate a bunch of unrelated child processes.

[swick]

Indeed, putting x-d-p-gtk into session.slice and also launching everything into their own cgroup in app.slice or both things we should do. Someone needs to put the work in and check all the places where we might launch something.

[smcv]

launching everything into their own cgroup

I think most of that would need to happen in GLib, because x-d-p-gtk mostly just calls g_app_info_launch_uris() or g_app_info_launch() or similar. The only explicit subprocess launch that I can immediately see is the app chooser dialog running gnome-software.

The desktop-independent x-d-p probably has the same problem, because it also calls g_app_info_launch_uris().

[Atemu]

if x-d-p-gtk launches an application - for example a web browser like Firefox or Chromium to implement the OpenURI interface, or a viewer like Evince or Xpdf to implement the OpenFile interface - then the web browser or viewer could end up also being in session.slice, which we probably don't want.

How could I verify whether this actually happens?

[swick]

The only explicit subprocess launch that I can immediately see is the app chooser dialog running gnome-software.

Right, that needs fixing then but otherwise it sounds like we could move it to session.slice.

[swick]

Mh, I skimmed the implementations of g_app_info_launch and I don't see it doing anything regarding the cgroup it ends up in so I guess this needs some work in glib first...