Dne 21. 12. 20 v 23:20 Aleksei Bavshin napsal(a):
On 12/21/20 1:53 PM, Neal Gompa wrote:
> On Mon, Dec 21, 2020 at 4:52 PM Aleksei Bavshin
> <alebastr89(a)gmail.com> wrote:
>>
>>
>>
>> On 12/21/20 8:28 AM, Ben Cotton wrote:
>>> == Documentation ==
>>>
>>>
https://www.freedesktop.org/software/systemd/man/systemd-oomd.html<br
>>> />
>>>
https://www.freedesktop.org/software/systemd/man/oomctl.html<br />
>>>
https://www.freedesktop.org/software/systemd/man/oomd.conf.html
>>
>>> Be aware that if you intend to enable monitoring and actions on
>>> user.slice, user-$UID.slice, or their ancestor cgroups, it is
>>> highly recommended that your programs be managed by the systemd
>>> user manager to prevent running too many processes under the same
>>> session scope (and thus avoid a situation where memory intensive
>>> tasks trigger systemd-oomd to kill everything under the cgroup). If
>>> you're using a desktop environment like GNOME, it already spawns
>>> many session components with the systemd user manager.
>>
>> This makes me slightly very concerned. According to cgls, I have
>> most of
>> the apps running directly under user-$UID.slice -> session-X.scope.
>> That
>> includes a compositor (sway) and a few applications that consume
>> uncomfortably close to 100% of available memory (firefox, thunderbird,
>> clangd, gcc, etc...).
>>
>> My understanding is that unless I configure all of the above to run
>> under dedicated scopes, an attempt to run a memory-intensive task would
>> make systemd-oomd terminate the whole user slice with all my apps.
>>
>> Is there anything that could be improved for that scenario? I don't
>> expect that all our desktop users would start using `systemd-run
>> --scope
>> --user` to launch their applications.
>>
>
> My understanding is that we intend to do exactly that for you
> automatically when you open an application through a desktop file. So
> it should be fine from that perspective.
>
Should I mention that this is happening not in GNOME and neither make
nor vim are using desktop files to start subprocesses? And there are
dozens of application launchers in Fedora repositories that aren't
aware of systemd or cgroups.
And I wonder what will be the behavior for applications, which I start
from my terminal? The most typical example for me is running GVim from
gnome-terminal.
Vít
I'm raising that point because I'd like to have at least a set of
recommendations for any alternative environments. So far it seems like
the impact outside of major DEs and standard desktop workflows wasn't
considered.
Don't take this as an antagonism to the proposal, I see the benefits
of systemd-oomd and will likely use it myself with a few shell
aliases, patches and config changes. It's just that as a maintainer of
one of those alternative desktop environments I have no idea how to
make that work in default configuration.
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
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@lists.fedoraproject.org