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
> On Mon, Jan 06, 2020 at 02:53:13PM -0600, Michael Catanzaro wrote:
> > On Mon, Jan 6, 2020 at 7:09 pm, Lennart Poettering
> > <mzerqung(a)0pointer.de> wrote:
> > > - facebook is working on making oomd something that just works for
> > > everyone, they are in the final rounds of canonicalizing the
> > > configuration so that it can just work for all workloads without
> > > tuning. The last bits for this to be deployable are currently being
> > > done on the kernel side ("iocost"), when that's in,
> > > oomd (or simplified parts of it) to systemd, so that it's just there
> > > and works. It's their expressive intention to make this something
> > > that also works for desktop stuff and requires no further
> > > tuning. they also will do the systemd work necessary. time frame:
> > > half a year, maybe one year, but no guarantees.
> > Asking around, I understand oomd only operates at the cgroup level,
> > i.e. it kills an entire cgroup at once, not individual processes. So
> > I understand this would also depend on GNOME-level work to ensure
> > individual applications get launched in their own systemd scopes,
> > yes?
> 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:
│ │ ├─1501571 /usr/bin/gnome-shell
│ │ ├─1501606 /usr/bin/Xwayland :0 -rootless -noreset -accessx -core -auth
-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
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
> 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
> It seems we're quite close! Do we just need to wait for
> gnome release and then we'll have everything nicely segregated?
Likely not perfect, but hopefully close enough for many purposes :)