SUMMARY When launching a program from Konsole and the program runs out of memory, Konsole terminates as well. Here is an extract from kernel logs: [ 4798.852688] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/user.slice/user-1000.slice/user@1000.service/app.slice/app-org.kde.konsole-0b1078c44601481893367fffe01d53f3.scope,task=python,pid=33408,uid=1000 [ 4798.852755] Out of memory: Killed process 33408 (python) total-vm:40125280kB, anon-rss:24510464kB, file-rss:4604kB, shmem-rss:0kB, UID:1000 pgtables:60432kB oom_score_adj:200 STEPS TO REPRODUCE 1. launch a memory-eater program; 2. wait until it fills the entire RAM and is killed by the kernel. OBSERVED RESULT The Konsole window disappears. EXPECTED RESULT The Konsole window should stay open, and report that the program has been terminated because of an OOM. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Fedora 39 (available in About System) KDE Plasma Version: 5.27.10 KDE Frameworks Version: 5.113.0 Qt Version: 5.15.12 ADDITIONAL INFORMATION The same behaviour is shown by Yakuake. On the other hand GNOME Terminal survives the killing of the process.
Unfortunately KDE software is not responsible for deciding which process to kill during out of memory events. Usually it is either the kernel OOM killer, and the systemd OOM killer, and we have no control over how these behave. If you find the current OOM killer unsatisfactory, you could try customizing those or using alternate OOM killers like https://github.com/rfjakob/earlyoom.
(In reply to fanzhuyifan from comment #1) > Unfortunately KDE software is not responsible for deciding which process to > kill during out of memory events. Usually it is either the kernel OOM > killer, and the systemd OOM killer, and we have no control over how these > behave. If you find the current OOM killer unsatisfactory, you could try > customizing those or using alternate OOM killers like > https://github.com/rfjakob/earlyoom. Thank you for the answer. But this occurs systematically and does not occur with GNOME Terminal. So there should be something in the design or behavior of Konsole that triggers the OOM killer to terminate it together with the child process. Any ideas on why this may be? If this is "not a bug" can we turn this into a wishlist item? I believe it can significantly impact the user experience in some cases, putting Konsole (and KDE software) behind competitors. It could be also interesting to understand whether this is distro-related. If people not using Fedora are not experiencing the same issue, I may file a bug report with Fedora as well.
Created attachment 165602 [details] attachment-282804-0.html i remember we had a merge request for this a while ago. On Tue, 6 Feb 2024 at 09:16 Massimiliano L <bugzilla_noreply@kde.org> wrote: > https://bugs.kde.org/show_bug.cgi?id=480884 > > --- Comment #2 from Massimiliano L <m.lincetto@gmail.com> --- > (In reply to fanzhuyifan from comment #1) > > Unfortunately KDE software is not responsible for deciding which process > to > > kill during out of memory events. Usually it is either the kernel OOM > > killer, and the systemd OOM killer, and we have no control over how these > > behave. If you find the current OOM killer unsatisfactory, you could try > > customizing those or using alternate OOM killers like > > https://github.com/rfjakob/earlyoom. > > Thank you for the answer. But this occurs systematically and does not occur > with GNOME Terminal. So there should be something in the design or > behavior of > Konsole that triggers the OOM killer to terminate it together with the > child > process. Any ideas on why this may be? > > If this is "not a bug" can we turn this into a wishlist item? I believe it > can > significantly impact the user experience in some cases, putting Konsole > (and > KDE software) behind competitors. > > It could be also interesting to understand whether this is distro-related. > If > people not using Fedora are not experiencing the same issue, I may file a > bug > report with Fedora as well. > > -- > You are receiving this mail because: > You are the assignee for the bug.
(In reply to Massimiliano L from comment #2) > Thank you for the answer. But this occurs systematically and does not occur > with GNOME Terminal. So there should be something in the design or behavior > of Konsole that triggers the OOM killer to terminate it together with the > child process. Any ideas on why this may be? > > If this is "not a bug" can we turn this into a wishlist item? I believe it > can significantly impact the user experience in some cases, putting Konsole > (and KDE software) behind competitors. > > It could be also interesting to understand whether this is distro-related. > If people not using Fedora are not experiencing the same issue, I may file a > bug report with Fedora as well. In general, the advice is to *not* operate your system in settings that frequently trigger the OOM killer. There are several ways to do that: - limiting the ram of memory-hungry processes (e.g., using systemd, or options to jvm) - use swap (zram offers a way to put swap inside ram, and you could always configure swap on harddrives) - upgrade your hardware If you must operate near regimes that saturate the memory, my suggestion is to custom configure an OOM killer, so you get more control over what is killed in OOM situations. The systemd and kernel OOM killers both use some sort of heuristics to decide which application to kill first. It is very hard for us to guarantee that konsole is not killed first -- in some cases, it might even be desirable to kill konsole first if more critical applications can continue.
(In reply to fanzhuyifan from comment #4) > In general, the advice is to *not* operate your system in settings that > frequently trigger the OOM killer. > There are several ways to do that: > - limiting the ram of memory-hungry processes (e.g., using systemd, or > options to jvm) > - use swap (zram offers a way to put swap inside ram, and you could always > configure swap on harddrives) > - upgrade your hardware The use case here is Konsole being used for development and debug. The large memory consumption would then be unintentional, either because the amount of required memory was miscalculated or because there is a memory leak in the program. But if the terminal gets killed, the stdout is lost and debugging gets more complicated. Of course logging to a file or limiting the memory available to the python interpreter would be valid alternatives. > If you must operate near regimes that saturate the memory, my suggestion is > to custom configure an OOM killer, so you get more control over what is > killed in OOM situations. > > The systemd and kernel OOM killers both use some sort of heuristics to > decide which application to kill first. It is very hard for us to guarantee > that konsole is not killed first -- in some cases, it might even be > desirable to kill konsole first if more critical applications can continue. It might be desirable to kill Konsole if Konsole was responsible for the memory consumption by itself and not because of a child process, but I get the point. Your comment clarifies the situation enough for me. Thank you again for the support.