While working with older machine with swap on and 2 GB ram, I frequently encounter behaviour well described as freeze:
- here, what is the best way to prevent out of memory oom freezes on linux
- here, computer freezing on almost full ram, possibly disk cache problem
- and here, system hanging when it runs out of memory
- overall seemingly long known bug
While all Q&A here focus mostly on
- tweaking with sysctl
- other proposed solution tweaking oom_score and praying OOM works
- setting up zram(swap compress)
- shell scripts of various  sorts 
- 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:
- Have the situation changed/improved in never kernels (say 4.0 +)
- Have the situation changed in never Ubuntu (custom patches? 12.04 +)
- Regardless of those two questions, I'm open to suggestions, that were not yet mentioned in Q&A above.
Regardless of those three questions above. I'm thinking about compiling own
/bin/loginbinary, 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?