You are not logged in.
I noticed that on compiling firefox on a recent desktop, the terminal would close near the end of a long build process. There is no sysctl to completely disable the setting in the latest stable (6.7.x) either. Some workarounds are to ssh to localhost and/or echo a magic value (-17) to the process's oom_adj under /proc.
Offline
It is an upstream linux kernel issue/feature request because I also saw it on debian "bookworm" trying to build a kernel using their make deb-pkg script logged into a KDE plasma desktop using their 6.1.x series and my own 6.7.2 built on a VM. It should be easy to reproduce. I also tried to apply an out-of-tree patchset (oompriority based on cgroups) which didn't work on a recent kernel source.
Last edited by slytux (2024-02-08 04:16:11)
Offline
Compiling Firefox requires a lot of memory, especially if you try to compile everything in memory; if you have less than 32G of RAM it is impossible to achieve this.
You can probably compile it with 16G of RAM and a big swap partition, but if you have less than that amount of memory, forget it.
In this post, I explain how I managed to compile it entirely in RAM with 32G: https://bbs.archlinux.org/viewtopic.php?id=290946
I have to add that I couldn't compile latest version (122) due to a compilation error.
Excuse my poor English.
Offline
I do have 32GB of RAM and it wasn't a compiling issue. I did not know what was causing it at first. The relevant files are mm/oom.c in the kernel sources and what I have found on the web is that RedHat might have maintained a patch.
Last edited by slytux (2024-02-09 19:16:36)
Offline
echo a magic value (-17) to the process's oom_adj under /proc.
The "magic" value just makes the process least favorably picked by the OOM killer
is an upstream linux kernel issue/feature request because I also saw it on debian "bookworm"
what I have found on the web is that RedHat might have maintained a patch.
Links?
You're running OOM - do you have swap and/or do you use either zswap or zram?
There're some userspace OOM daemons that'll trigger before the kernel does and might allow you to steer away from the terminal process.
https://wiki.archlinux.org/title/Improv … conditions
Offline
I was testing a laptop and wanted to compile a kernel natively on it. It can still trigger without systemd-oomd.service on.
Offline
Err… what?
1. building the kernel will require far less RAM than building firefox - but on eg. a swapless 2GB setup running a big DE and a browser will likely run OOM as well.
2. the idea is to use one of the userspace OOM daemons to prevent the kernel OOM response and gain better control (in advance) of which PIDs get sacrificed.
Offline