13

It is explained here: Will Linux start killing my processes without asking me if memory gets short? that the OOM-Killer can be configured via overcommit_memory and that:

  • 2 = no overcommit. Allocations fail if asking too much.
  • 0, 1 = overcommit (heuristically or always). Kill some process(es) based on some heuristics when too much memory is actually accessed.

Now, I may completely misunderstand that, but why isn't there an option (or why isn't it the default) to kill the very process that actually tries to access too much memory it allocated?

Improve this question
7
  • What if a critical system process asks for too much memory ?
    – Lawrence
    Commented Jun 10, 2014 at 8:40
  • In the first place - it can do this thing. But, the biggest problem with that question is that in all likelihood if a process is asking for memory then it is being newly executed - or, in other words, this is a new process involved in very current processing. Would you rather the OOM allowed your not-opened-for-3-days im client to keep on wasting system memory or would you rather YouTube actually loaded some time this year? linuxatemyram.com
    – mikeserv
    Commented Jun 10, 2014 at 8:44
  • 3
    This is what the no overcommit option essentially does. If a process asks for too much memory, it fails. If it checks for the error, it will usually kill itself; if it doesn't, it will probably get a Segmentation Error when it tries to dereference the null pointer that malloc() returns, and it will crash.
    – Barmar
    Commented Jun 11, 2014 at 19:11
  • 1
    These guys always use the same arguments, but such problems never happen on Windows side of things, even in machines with only 4GB of memory. A common example is Linux not killing the obvious culprit, the internet browser using 2GB for a single process, while it goes on to kill all my panel and background processes. Sometimes, the OOM even kills my Pulseaudio process, while it lets the browser escape intact. It's just broken, let's just admit it at this point. Obsolete. This is an area of Linux that is in dire need of new talents to update it. Swapping too, not updated since the 90's.
    – Winampah
    Commented May 19, 2021 at 10:08
  • 2
    I love this ridiculous statements that it's not a problem on windows. It is same problem on windows, you just don't know how windows works. You see windows has no qualms in growing it's swap on demand.
    – etosan
    Commented Jan 27, 2023 at 17:41

2 Answers 2

Reset to default
24

Consider this scenario:

  • You have 4GB of memory free.
  • A faulty process allocates 3.999GB.
  • You open a task manager to kill the runaway process. The task manager allocates 0.002GB.

If the process that got killed was the last process to request memory, your task manager would get killed.

Or:

  • You have 4GB of memory free.
  • A faulty process allocates 3.999GB.
  • You open a task manager to kill the runaway process. The X server allocates 0.002GB to handle the task manager's window.

Now your X server gets killed.

It didn't cause the problem; it was just "in the wrong place at the wrong time". It happened to be the first process to allocate more memory when there was none left, but it wasn't the process that used all the memory to start with.

Improve this answer
4
  • To extend your example it means that if a process was consuming 99.999% of your memory you'd never be able to kill it since anything that could kill it would require memory and thus get itself killed before the errant process could be killed!
    – Sled
    Commented Jun 10, 2014 at 17:22
  • 14
    Mind you, this is the Linux philosophy, not a necessary fact. Windows 3.0 solved it by having sufficient memory reserved for OOM handling, including the necessary dialogs.
    – MSalters
    Commented Jun 10, 2014 at 19:20
  • @MSalters: That doesn't really apply to the example, though; The example was about a process that has reserved nearly all memory, ie. not enough to get itself OOM killed. Obviously there has to be enough memory reserved for OOM handling on any OS. But the process that invokes the OOM handling would be the next process that happens to reserve memory, not the misbehaving one. Unless, of course, you meant that Windows 3.0 always had enough memory reserved for running task manager, or that the OOM handler always prompted the user for the process to kill. (Which != killing the offending process)
    – Aleksi Torhamo
    Commented Jun 16, 2015 at 22:58
  • 3
    @AleksiTorhamo: I indeed meant the latter. Windows 3.0 didn't have a fullblown task manager, it had the famous blue screens whose memory was preallocated.
    – MSalters
    Commented Jun 17, 2015 at 7:24
-1

This problems has been plaguing me for the longest time, and all I find out there are the almighty "Linux defenders" preaching that the OOM Killer is the ultimate tool ever invented. (I wonder if most of these guys even use Linux on a daily basis because their remarks sound distant to what I see in reality...)

From my experience with it (many many freezes and crashes, hard reboots and a lot of pain, hours wasted that will never get back) my understanding of the OOM Killer is that it is BROKEN, it does NOT work and it's fundamentally flawed in the way it is designed because (as original post mentions) it won't kill the main offender (the app that is allocating more memory, like Windoze does...) Instead, it kills the processes SURROUNDING the main big process, which brings no results whatsoever.

To me this Linux OOM Killer looks like something that was designed way back when computers had less than 128 MB of RAM and before internet browsers were a thing. It's unpractical and innefective to today's standards.

These commands should proove useful for you to assign to a keyboard shortcut:

First, test what process you want to kill using this command:

ps aux | grep STRING
ps aux | grep PORTION_OF_NAME_WITHOUT_QUOTES_OR_SPACES

If it shows the process you want to kill, then put it in the script below inside the parenthesis.

#!/bin/bash
#
kill -9 $(ps aux | grep type=renderer)
# the above will kill all my Chromium processes
# without having to restart my entire browser or losing progress
# incognito window will be kept alive, instead of lost
#
sudo killall tumblerd
# (optional)

Or even better:

sudo apt remove tumbler
Improve this answer
4
  • Rant about the OOM reaper aside, this doesn't answer the question asked. It would be more helpful to answer the question directly or provide more information about how the reaping process works. More useful information is here: lwn.net/Articles/590960
    – Liczyrzepa
    Commented Jul 14, 2020 at 22:34
  • More over, you can always disable overcommit - then your Linux will behave more like BSDs, and the last program allocating more memory then is availible will fail, and any program trying to allocate more than is availible will fail as well in the moment of allocation and crash. Of course you will sometimes have problem connecting and fixing the OOM issue, as described above, though. Finally windows gets stuck same way even worse.
    – etosan
    Commented Jan 27, 2023 at 17:39
  • There are a lot of false assertions here. And a "solution" which would not work in an OOM scenario. The POINT of overcommit is to deal with greedy programs that want memory they won't use. The POINT of the OOM killer is to allow the system to survive and log facts when its current configuration is not appropriate so that YOU can fix the configuration to PREVENT the error recurring.
    – symcbean
    Commented Jan 28, 2023 at 0:47
  • I want to add that swapping is fundamentally broken too in linux. :)
    – JPT
    Commented Feb 2 at 16:54

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .