SUMMARY systemd-oomd only tracks and kills at the cgroups level. If a child process in Konsole consumes too many resources, the entire Konsole cgroup is subject to being killed by oomd including all of its child processes. This is inconvenient. See downstream bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1977610 SOFTWARE/OS VERSIONS Linux/KDE Plasma: Fedora 34 KDE, systemd 248 ADDITIONAL INFORMATION On Fedora with GNOME, vte moves each process into its own scope, and thus its own cgroup assignment. The code is here: https://gitlab.gnome.org/GNOME/vte/-/blob/master/src/systemd.cc I think the solution is Konsole needs a similar enhancement, that way each tab's process(es) is effectively tracked in its own cgroup, and only that tab is subject to being killed off by oomd.
This is quite nice. thanks for pointing that out.
Is there any easy way to test this? I'v tested tail /dev/zero but that just eat my whole memory and I couldn't even move the mouse.
The easiest way to verify cgroup creation/layout is to run cat /proc/self/cgroup in a terminal tab. systemd-oomd will always kill an entire cgroup. So if all the child processes are in the same cgroup then they will all be killed together.
Good idea!
A possibly relevant merge request was started @ https://invent.kde.org/utilities/konsole/-/merge_requests/866
Git commit 1525ee3b5ea58b09d551f41b0bd6f0f91589e070 by Kurt Hindenburg, on behalf of Theodore Wang. Committed on 29/08/2023 at 01:59. Pushed by hindenburg into branch 'master'. Create separate cgroups for processes of each tab Currently, all the processes created by the application are housed within the application's cgroup without any futher categorisation. This causes the entire application to be killed if a process in the aforementioned cgroup triggers an OOM event. To prevent the entire application from being killed, a new child cgroup is created for each new tab. Child cgroups for individual tabs are named according to this template "tab([session pid for the tab]).scope". "Background" processes (e.g. such as the main process for running konsole) are stored in the child cgroup "main.scope". This restricts the OOM event to only killing the tab which contains the offending process. To prevent the entire application from being killed, a new child cgroup is created for each new tab. Child cgroups for individual tabs are named according to this template "tab([session pid for the tab]).scope". "Background" processes (e.g. such as the main process for running konsole) are stored in the child cgroup "main.scope". This restricts the OOM event to only killing the tab which contains the offending process. M +2 -0 src/CMakeLists.txt M +7 -0 src/MainWindow.cpp M +226 -3 src/ProcessInfo.cpp M +3 -1 src/ProcessInfo.h M +1 -1 src/session/Session.cpp A +18 -0 src/settings/MemorySettings.cpp * A +18 -0 src/settings/MemorySettings.h * A +62 -0 src/settings/MemorySettings.ui M +10 -0 src/settings/konsole.kcfg The files marked with a * at the end have a non valid license. Please read: https://community.kde.org/Policies/Licensing_Policy and use the headers which are listed at that page. https://invent.kde.org/utilities/konsole/-/commit/1525ee3b5ea58b09d551f41b0bd6f0f91589e070
What about OpenRC users? Is it make sense to use a separate cgroup for each tab on OpenRC?
Created attachment 161399 [details] attachment-419896-0.html On OpenRC, each tab already gets a new cgroup via the autocgroup feature provided by the kernel since 2.6.38. AFAIK, SystemD wants more visibility, which us why it wants processes to use its cgroup management API, so that then it can manage those cgroups in a more personalized way. On Sunday, September 3, 2023, Yury Zhuravlev <bugzilla_noreply@kde.org> wrote: > https://bugs.kde.org/show_bug.cgi?id=439805 > > Yury Zhuravlev <stalkerg@gmail.com> changed: > > What |Removed |Added > ------------------------------------------------------------ > ---------------- > CC| |stalkerg@gmail.com > > --- Comment #8 from Yury Zhuravlev <stalkerg@gmail.com> --- > What about OpenRC users? Is it make sense to use a separate cgroup for > each tab > on OpenRC? > > -- > You are receiving this mail because: > You are the assignee for the bug.