8 ms·
Tangential, but does anyone know why in 2026 and on Debian 13, my machine still hangs when some process exhausts RAM? Is there really no higher-priority kernel
by ducktective 6d ago
Tangential, but does anyone know why in 2026 and on Debian 13, my machine still hangs when some process exhausts RAM?
Is there really no higher-priority kernel process to prevent total freeze of the system and send a SIGKILL to the culprit process when such a scenario happens?
- elektrontamer 6d agoI always install earlyoom for that reason
- dev_hugepages 6d agoThis is called an oomkiller. The kernel has one but it kicks in very late and the kernel prefers to do page trashing instead of killing processes. systemd-oomd should be integrated in systemd, you can configure it to your liking and see if it improves your problem.
- ButlerianJihad 6d agoI believe that you mean: https://en.wikipedia.org/wiki/Thrashing_(computer_science) https://en.wikipedia.org/wiki/Thrashing_(computer_science) Chris Siebenmann discusses when the OOM killer triggers: https://utcc.utoronto.ca/~cks/space/blog/linux/OOMKillerWhen https://utcc.utoronto.ca/~cks/space/blog/linux/OOMKillerWhen Chris disables systemd-oomd after it obliterates his X session with no explanation: https://utcc.utoronto.ca/~cks/space/blog/linux/SystemdOomdNowDisabled https://utcc.utoronto.ca/~cks/space/blog/linux/SystemdOomdNo...
- rovr138 6d ago> First off, this is exactly how systemd-oomd is supposed to behave under memory pressure. The documentation is specific on this; systemd-oomd itself says: > > [...] If the configured limits are exceeded, systemd-oomd will select a cgroup to terminate, and send SIGKILL to all processes in it. [...] > By having the user@.service template be enrolled in systemd-oomd, Fedora made the cgroup that systemd-oomd would select to be killed be all of your processes (across all of your sessions, if you have more than one). ... Maybe *Fedora* has fixed or improved in the last 4 years. Or maybe they don't run Fedora.
- BenjiWiebe 6d agoOne thing Fedora does now, is use zram. In my experience it works really well. I wonder why my computer is a bit sluggish, and find out I have several gigs in zram. If that was in swap on a disk, it would be really painful.
- MrDrMcCoy 5d agoIf it were swap on disk fronted by zswap, it'd be even better ;)
- rwmj 6d agoI'm a Fedora developer and I can assure you that Fedora's behaviour when it runs out of memory is still terrible.
- miladyincontrol 6d agoAdding to this, glad systemd-oomd finally added solid rulesets in 261 Made it far easier to target any containers that got too hot rather than ever risk anything higher priority.
- SoftTalker 6d agoI wish there was an easy way to configure it to say "target user processes first, specifically java (or these days python)" as in my experience they are always the culprits. Processes owned by system accounts or root should be the last ones killed.
- bigstrat2003 5d agoSimilarly, in the past I have wished for the ability to exempt a process from the oomkiller. I've run servers where the top memory user was also the server's entire reason for existence, and if that process gets killed the server may as well be down. It would literally have been better for any other process to get killed, but it was always the application process because of the memory usage.
- mixmastamyk 5d agosystemd-oomd works reasonably well and there is source code. Perhaps claude can help add more detailed policy support to it. Just found this comment: https://news.ycombinator.com/item?id=49663299 https://news.ycombinator.com/item?id=49663299
- negrel 6d agoOS are designed to fully exploit available resources, Linux tries its best before triggering an OOM kill. I recommend using the earlyoom if you want more aggresive oom kill: https://github.com/rfjakob/earlyoom https://github.com/rfjakob/earlyoom The README contains a lot of interesting information.
- oomedfornight 6d agoA strange behavior I sometimes run into with earlyoom is that I try to start up some buggy software of mine and it seemingly never starts. It took a long evening to figure out that it gets earlyoom'd immediately because it tries to allocate too much. Previously the very familiar hitching and freezing was a very easy sign of what kind of issue I was dealing with
- CoastalCoder 6d agoJust mentioning this in case it's helpful: If you know ahead of time which programs / processes are at risk of unacceptably high memory usage, check out "ulimit".
- afishhh 6d agoSet `/sys/kernel/mm/lru_gen/min_ttl_ms` at boot (see https://docs.kernel.org/admin-guide/mm/multigen_lru.html https://docs.kernel.org/admin-guide/mm/multigen_lru.html). User-space OOM killers never really worked for me and imo are not a proper solution anyway. This option instead lets you make the kernel OOM killer actually work for desktop use. Currently have it set to `1000` and it works very well for me (don't remember the last time I had a full system freeze due to OOM).
- pestatije 6d agonot tangential at all...try setting up a swap partition
- jenders 6d ago[flagged]
- trompetenaccoun 6d agoThis has finally been fixed in the latest Ubuntu version (26), it now force closes the culprit.
- jillesvangurp 6d agoAh nice. I was dealing with that in one of our environments where a security update ended up causing apt to use more memory than usual so the oom killer nuked our elasticsearch process to "free up some memory". And since that happened on all nodes around the same time, it took out the entire cluster. If you are not familiar, random, uncontrolled node restarts in any kind of multi node database or search product are a great way to trigger outages. So, not great. I've had quite a few encounters with the oomkiller killing processes that were important and didn't need killing. Or as I like to phrase it "killing the one reason this server exists". These days the way to size a server is "have enough memory to run whatever you need running + at least half a GB for whatever apt might randomly demand at any point". And guess what, memory tends to be expensive in cloud environments so people tend to get vms with as little as half a GB of ram.
- dagenix 6d agoHow did they fix it?
- noisem4ker 5d agoI couldn't find any information about that. Do you have something to back it up (news articles, changelog entries), or was it just your subjective experience?
- fc417fc802 6d ago> does anyone know why In a nutshell, overcommit. It's more or less broken by design but it's also incredibly practical so pretty much everyone does it. Couple that with the fact that it's difficult bordering on impossible to correctly determine the culprit. If you've got 16 GB RAM and the user launches 3 processes each of which attempts to use 8 GB who should you kill?
- wongarsu 6d agoNotably windows doesn't use overcommit, and degrades much more gracefully under memory pressure. The biggest tradeoff is the amount of disk space consumed by a page file that also has to reserve space for unused pages that have been allocated but never been swapped in. On linux you can turn overcommit off, but there's too much software written around the assumption that overcommit is on
- fc417fc802 6d agoIs that still the case today? Notably (IIUC) overcommit is required for certain security measures. I believe it was chromium that I noticed mmaping somewhere north of 1 TB of memory on startup so that it can do (again IIUC) something akin to ASLR internally.
- wongarsu 6d agoOn Windows you can achieve something like manual overcommit by calling VirtualAlloc with just MEM_RESERVE. That gives you a continuous space in your process's virtual address space, without actually backing it with any physical pages. Kind of like what a malloc does on linux But where linux would automagically back those pages once you use them, Windows requires you to actually ask for those pages to be backed by something (physical memory or page file) by calling VirtualAlloc with MEM_COMMIT on the range you actually want to use
- fc417fc802 6d agoAt a glance that seems like a much more sensible design. I guess it's dead in the water for posix on account of fork being CoW? This is quite the rabbit hole. I wonder if programming languages ought to be designed in such a way to accommodate a preemptive signal indicating allocation failure in place of a page fault? Rather than malloc returning null or etc.
- pndc 6d agoI had a 1GB Debian VM which started freezing (requiring a hard reboot) after a routine aptitude upgrade to apply security patches. It was indeed caused by low memory, but not out of memory as there was still enough swap space remaining. The culprit turned out to be the kernel itself, and rolling back to a 6.1 series kernel made the problem go away. I see that Linus's love for vibe-coding is already paying dividends.
- BoredomIsFun 6d agoIt does not if you switch swapp off and use zram instead. I am typing right now on such a setup wityh 16 GiB ram and it occasionally, once a week or so, kills my firefox due to oom. If you are you using disk swap - not sure why would if you have a SSD, but I once heard some justification for doing that - then install early OOM.
- cassianoleal 6d ago> switch swapp off and use zram instead Or zswap instead of zram. https://chrisdown.name/2026/03/24/zswap-vs-zram-when-to-use-what.html https://chrisdown.name/2026/03/24/zswap-vs-zram-when-to-use-... https://linuxblog.io/zswap-better-than-zram/ https://linuxblog.io/zswap-better-than-zram/
- joshAg 6d agoDon't worry, it's not just you: https://lkml.org/lkml/2019/8/4/15 https://lkml.org/lkml/2019/8/4/15 It's because linux is a toy OS. Specifically, it overcommits memory in the hope/assumption that it won't all be used at once, but doesn't have a way to gracefully degrade when applications collectively want to use more memory(+swap) than it actually has. You can turn off overcommit, but applications are designed with the overcommitting feature in mind, so your experience might not be as good as you were hoping for. Making a massive swap space helps a little bit. It's better to just never let your actual memory usage go above 85% to 90%. It's fine to go above if you're trying to optimize a server with a specific set of processes to wring every last bit of efficiency out of it, but not for general desktop computing. If it really bothers you OpenBSD (edit: thanks for the reminder TimTheTinker) and Illumos don't allow overcommit at all and Windows handles this situation much more gracefully, so WSL is an option too. If you don't mind Oracle (i do), solaris also doesn't allow overcommit.
- nicman23 6d agoor use the system's oom ?
- joshAg 6d agoThat's what's breaking the system and causing freezes. You can tune it a bit to minimize when it happens, but not get rid of the issue entirely.
- SoftTalker 6d ago... which then kills sshd, locking you out of being able to get in and do any recovery.
- nicman23 5d agothe system will restart sshd?
- joshAg 5d agothe system will kill whatever it damn well pleases. You can tune it with priorities to ask it to try to not kill that, and once it kills your sshd once, you'll probably configure it to exempt sshd from being OOM killed at all. That doesn't fix the memory pressure or hanging or stalling, but you'll at least be able to log into the box still instead of dragging out a serial cable.
- Narishma 5d agoLinux and the software running on it are generally very bad at handling out-of-memory situations.
- PunchyHamster 5d agoIt should eventually kill it. But having swap means it will try to use it as RAM which might delay/freeze system hard