Re: systemd-oomd blows away the gnome-shell desktop session
I suspect that this may have been a swap-based kill and gnome-shell was using the most swap at the time. If you do `journalctl --unit systemd-oomd` do you see "systemd-oomd[]: Killed due to " ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Question related to systemd-oomd
"Scope" from that Wiki is referring to the scope section of the proposal (https://fedoraproject.org/wiki/Changes/EnableSystemdOomd#Scope). As of systemd 248 the missing features are landed so ManagedOOMMemoryPressureLimit= is now available (this was named something else in 247). ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora 34 Change: Enable systemd-oomd by default for all variants (System-Wide Change)
> Earlyoom maintainer here. I think it's too early to switch to > systemd-oomd, because it was just merged to the systemd codebase and is > still an experimental feature. Hi! I authored the PR for systemd-oomd. It was merged as a feature for "preview" rather than "release", but that was so the interface could be improved based on feedback. The feature itself was tested against a subset of Facebook's servers and it behaves the same as the stand alone oomd that we've been running for years (minus the knobs that were not implemented in systemd-oomd). > In earlyoom we have a list of processes that cannot be killed (eg. > dnf/packagekit/etc.), so it is absolutely safe to use as a default > userspace OOM solution. We currently don't know anything about the > systemd-oomd safety for regular use on end user desktops. We can't even > test it on the current stable Fedora release. PSI takes into account cgroup memory protections so you can bias away from cgroups with critical apps by setting MemoryLow= to the appropriate values to prevent reclaim. > That's why I think this change need to be postponed to Fedora 35 (opt-in > in F34 and default in F35). I'm actually not opposed to that. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: Fedora 34 Change: Enable systemd-oomd by default for all variants (System-Wide Change)
I think so. I designed the systemd-oomd interface to be general enough to eventually support sending d-bus signals in addition to or in place of killing cgroups with SIGKILL. But I'm uncertain if it can be implemented before the freeze. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
