Linux OOM Killer

That's pretty much why we use vm.panic_on_oom = 1 as you have no idea about what's going to be killed...

Yes, but that's more like fork or malloc failing in the first place than letting you run and then randomly killing something when the system gets overcomitted

You can turn off overcommit.The basic idea isn’t that having malloc return NULL on failure is worse than killing a random process when any process runs out of memory. The idea is that programs often ask for memory that they don’t need, or don’t need right away.When a program actually uses too much memory, there isn’t a way to signal failure, so the OOM gets involved. If this is wrong, turn off overcommit. Unfortunately, overcommit is a system-wide setting, so individual programs can’t opt

Until the kernel kills you for being OOM.

How can you handle OOM if your process gets killed by the kernel for using to much memory?

Same thing as everyone else: play russian roulette with the OOM-killer and hope that whatever was important to the user didn't get destroyed. Can't really do anything about the OS lying to you.

The original poster is almost certainly talking about Linux's overcommit policy: http://opsmonkey.blogspot.com/2007/01/linux-memory-overcommi...You can't adopt a defensive / offensive stance with regards to out-of-memory issues, because on Linux... malloc doesn't fail when you run out of physical memory.Your "error"

If you OOM, it's gonna crash.

But then we end up with the OOM Killer, which is awful - randomly kill the biggest process because "reasons".... It would be better if the OS could say no.

Linux supports overcommitted memory and so will lie to your application about memory availability. When I tested several common open-source applications in a memory-constrained environment none of them, except for the Java VM, handled OOM conditions gracefully. I came to the conclusion it's not worth the programming effort unless your application will specifically expect this condition to occur.