While working with older machine with swap on and 2 GB ram, I frequently encounter behaviour well described as freeze:

While all Q&A here focus mostly on

  • tweaking with sysctl vm.min_free_kbytes and vm.swappiness
  • other proposed solution tweaking oom_score and praying OOM works
  • setting up zram(swap compress)
  • shell scripts of various [1] sorts [2]
  • or even "advices" to buy more ram etc.

I find those solutions palliatives. I understand from reading kernel documentation, that even if OOM is made to behave, it can work in two "modes" for now:

  • either kills most memory hungry process (usually)
  • or kills memory 'offender' which is last process that actually tried to allocate memory.

Neither of this solution actually satisfies me. I came to conclusion that I DON'T want OOM to run killing either random or last process, yet I want to maintain system operational. I want to decide what to kill on my own, yet without tweaking oom_score for processes.


What I want to know/do, is:

  1. Have the situation changed/improved in never kernels (say 4.0 +)
  2. Have the situation changed in never Ubuntu (custom patches? 12.04 +)
  3. Regardless of those two questions, I'm open to suggestions, that were not yet mentioned in Q&A above.
  4. Regardless of those three questions above. I'm thinking about compiling own /bin/login binary, modified that:

    • it would allocate configurable amount of memory (ex. 8MB)
    • it would copy/fork configurable userspace TUI (ex. htop) (see this)
    • parent would put child process into suspend by sending it SIGTSTP (in order for it not to consume cpu), perhaps close child fd's.
    • parent would then send SIGTCONT to child only when user properly authenticated. Perhaps also restore child fd's if closed for security reasons,
    • this login-emergency binary would be executed by upstart/systemd or whatever init binary, running probably also with elevated permissions, to allow killing any desired process.

5. Does this approach seem sane or is this overkill? Any security flaws visible at glance?

  • If you're frequently having OOM issues, then you either need more RAM or you need to limit the number or size of programs you're running. Tweaking the OOM killer not to kill certain apps will just mean it has to find another app to kill to reclaim memory . Sending a SIGTSTP to a process will not help; it may stop using CPU time, but it's still sitting in virtual memory. – Karen B Jun 17 '16 at 17:54
  • That is almost like spending a month replacing a flat tire with a shopping cart wheel. My suggestion for systems with swap and little RAM is zram! It is very efficient in balancing swap efficiency. – Julie Pelletier Jun 17 '16 at 17:54
  • @KarenB this machine is at its limit, cannot support more RAM. JuliePelletier I find swap compression not a solution, with reasons too long for this comment and not relevant enough to add explanation for question, but thanks for suggestion anyways. – JustMe Jun 17 '16 at 17:55
  • What is more, I'm aware that in my case turning off OOM is rather needed (since I can't control what is going to be killed other that tweaking oom_scores, which is rather nonsense - if I expected to run out of memory I would free/run less programs before it happened, and wouldn't need to rely on OOM). – JustMe Jun 17 '16 at 18:02
  • You're still overlooking the obvious solutions: either get a bigger box or limit what is run on this box in the first place to decrease frequency of overallocation of memory. If you can't do either, you could improve swap perf by putting that on a faster/different disk than your root disk. – Karen B Jun 17 '16 at 18:07

Your Answer

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

Browse other questions tagged or ask your own question.