Doing a bit of research I found it it is possible to tune or even make certain processes immune against the OOM killer by poking a value into /proc/pid/oom_adj I do of course need to find pid for my process using pidof or pgrep or something like that and make a script that I run once all my processes are up and running.

The problem with the OOM killer is just like with any other killer. It may look sane and rational on the surface but deep down they are in fact seriously disturbed, quite insane and often incapable of making a correct judgement.

Now I personally don't mind a little killing as long as I know what is going on and have a certain control over the victims (calm down folks, I am talking about the computer stuff) so I am looking for a better way to protect certain processes against the dreadded OOM killer so that I don't have to run a script everytime all my progs are running or whenever I start a new program. Any ideas to how to easily achieve this?


You should not be relying on OOM killer to manage your processes. OOM killer is a measure of last resort, when the only other alternative is a system crash. E.g. all cache and disk buffers memory was flushed and committed, everything that can be swapped out/discarded is processed, and you still don't have enough memory... Obviously you don't want your running system to ever reach this state.

Because of the strict constrains that OOM killer operates under (cannot allocate more memory, cannot swap in other processes, etc.), it will kill processes you don't want to be killed to relieve memory pressure.

I think if your system just doesn't have enough memory, you need to add more memory or swap space, depending whether you're running out of physical memory or total virtual memory.

If, on the other hand, you have a few runaway processes that consume too much memory from time to time, due to a memory leak or some other bug, you can control that via other means:

  1. Set ulimit -m before starting the offending process and limit how much memory that process can allocate.

  2. Restart the offending process gracefully on a schedule via cron, if there is a memory leak and it is fairly predictable.

In any case, OOM killer is not your friend, it's a loose cannon :-/

  • it is a Debian 64bit system with 8GB of ram and 6GB of swap space. I also know what process is causing the trouble. I will check out ulimit as an option tomorrow. Thanks for your advice so far! – Waxhead Jan 1 '13 at 1:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.