On Tue, 2020-01-07 at 10:21 +0000, Zbigniew Jędrzejewski-Szmek wrote: > On Tue, Jan 07, 2020 at 11:07:49AM +0100, Benjamin Berg wrote: > > On Tue, 2020-01-07 at 09:47 +0000, Zbigniew Jędrzejewski-Szmek wrote: > > > I wanted to ask about this too... but didn't know where ;) > > > As of today, gnome-shell in F31 seems to start almost everything > > > as separate systemd user scopes: > > > > > > - various services started automaticlly like /usr/libexec/gsd- > > > power, > > > /usr/libexec/gsd-sound, etc. > > > > > > - flatpaks (this seems to be new, I had them running under > > > gnome-shell-wayland.service last week!) > > > > Hmm, pretty sure flatpaks have always created their own scopes. > > I'm quoting from my mail from this same thread: > > │ ├─gnome-shell-wayland.service > │ │ ├─1501571 /usr/bin/gnome-shell > │ │ ├─1501606 /usr/bin/Xwayland :0 -rootless -noreset -accessx -core > -auth /run/user/1000/.mutter-Xwaylandauth.SCXID0 > -listen 4 -listen 5 -displayfd 6 > │ │ ├─1501713 ibus-daemon --panel disable -r --xim > │ │ ├─1501718 /usr/libexec/ibus-dconf > │ │ ├─1501719 /usr/libexec/ibus-extension-gtk3 > │ │ ├─1501724 /usr/libexec/ibus-x11 --kill-daemon > │ │ ├─1501980 /usr/libexec/ibus-engine-simple > │ │ ├─1503586 /usr/lib64/firefox/firefox > │ │ ├─1503691 /usr/lib64/firefox/firefox -contentproc -childID 2 > -isForBrowser ... > │ │ ├─1503701 /usr/lib64/firefox/firefox -contentproc -childID 3 > -isForBrowser ... > │ │ ├─1503747 /usr/lib64/firefox/firefox -contentproc -childID 4 > -isForBrowser ... > │ │ ├─1520219 bwrap --args 35 telegram-desktop -- > │ │ ├─1520229 bwrap --args 35 xdg-dbus-proxy --args=37 > │ │ ├─1520230 xdg-dbus-proxy --args=37 > │ │ ├─1520232 bwrap --args 35 telegram-desktop -- > │ │ ├─1520233 /app/bin/Telegram -- > │ │ ├─1540753 pavucontrol > ... (Oh, what is the command to get this output?) This is not what I am seeing here. My gnome-shell cgroup only contains the gnome-shell, Xwayland and ibus. And I have separate .scope units for Telegram (flatpak-org.telegram.desktop-2162569.scope), evolution (gnome-launched-org.gnome.Epiphany.desktop-2162690.scope), … And I am pretty sure that flatpak/bwrap has always taken care of scoping flatpaks correctly. Benjamin > > So maybe a bug? I'll keep watching if it happens again. > > > > Stuff started from the run dialog (alt-f2) and from > > > the overview still seems to land in gnome-shell-wayland.service, > > > but maybe this is fixed in gnome-shell 3.35? > > > > This should have changed with the gnome-shell 3.34.2 update in > > Fedora > > 31. It may be that it has not reached rawhide yet though. > > I'm still on gnome-shell-3.34.1-4.fc31.x86_64. I'll try the latest > version. > > > > Another issue is that things that are started through the gnome > > > terminal also land in gnome-terminal-server.service. They need to > > > get their own scopes to make resource allocation robust. > > > > Do you think we should just place each VT into its own scope? > > Yes. Everything starting at the shell (or whatever command is > configured as the "payload", should get its own scope) and a separate > set of resources than gnome-terminal-server.service. > > > That seems like a reasonable start in principle, though graphical > > applications launched from the terminal may still not be moved into > > their own scope then. > > I think it is OK. After all, starting graphical applications from > the terminal is a special case. If desired, the user may run > 'systemd-run --user foo' if they want to segregate it. (Actually, > we might teach some apps to put themselves into a scope when started > from a command line. This makes sense for stuff like firefox, but > also > screen/tmux and others. But I consider this a completely separate > issue.) > > Zbyszek > > > > It seems we're quite close! Do we just need to wait for another > > > gnome release and then we'll have everything nicely segregated? > > > > Likely not perfect, but hopefully close enough for many purposes :) > > > > Benjamin > > _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
