解释
在使用具有交换功能和 2 GB 内存的旧机器时，我经常遇到被描述为冻结的行为：
- 这里，在 Linux 上防止内存不足 OOM 冻结的最佳方法是什么
- 这里，计算机几乎满内存时冻结，可能是磁盘缓存问题
- 和这里，内存不足时系统挂起
- 总体而言似乎早已为人所知的错误
虽然这里所有的问答主要集中在
- 使用 sysctl 进行调整
vm.min_free_kbytes和vm.swappiness - 其他建议的解决方案调整 oom_score 并祈祷 OOM 有效
- 设置 zram（交换压缩）
- 各种shell脚本[1]排序[2]
- 甚至“建议”购买更多内存等等。
我发现这些解决方案只是治标不治本。我从阅读中了解到内核文档，即使 OOM 能够正常工作，它目前也可以在两种“模式”下工作：
- 要么杀死大多数内存消耗大的进程（通常）
- 或杀死内存“罪犯”，这是实际尝试分配内存的最后一个进程。
这两种解决方案实际上都不能让我满意。我得出的结论是我不希望 OOM 运行杀死随机或最后一个进程，但我想保持系统运行。我想自己决定要杀死什么，但不调整进程的 oom_score 。
问题
我想知道/做的是：
- 在从未内核中情况是否有所改变/改善（例如 4.0 +）
- Ubuntu 中的情况是否有所改变（自定义补丁？12.04 +）
- 不管这两个问题，我都愿意接受建议，上面的问答中还没有提到的。
抛开以上三个问题不谈。我正在考虑编译自己的
/bin/login二进制文件，修改为：- 它将分配可配置的内存量（例如 8MB）
- 它将复制/分叉可配置的用户空间 TUI（例如 htop）（请参阅这）
- 父进程会通过向子进程发送 SIGTSTP 将其置于挂起状态（为了使其不消耗 cpu），也许会关闭子进程的 fd。
- 仅当用户经过正确身份验证时，父级才会向子级发送 SIGTCONT。如果出于安全原因关闭，也许还可以恢复子文件，
- 这个登录紧急二进制文件将由 upstart/systemd 或任何 init 二进制文件执行，也可能以提升的权限运行，以允许杀死任何所需的进程。
5. 这种方法看起来明智还是太过分了？是否存在一眼就能看出的安全漏洞？