我有一台 Ubuntu 12.04 服务器，它刚刚崩溃，原因非常明显：30 多个apt-check进程消耗了所有内存，OOM 终止程序启动，终止了重要服务。我不确定这些apt-check进程来自哪里，但我猜我的 Nagios/Icinga 插件check_apt可能会使用它，并且byobu状态行可能想要显示其输出。我猜有些东西被锁定了，所有进程都在等待，但占用了内存。
我如何才能防止apt-check系统上有这么多实例？这对我来说毫无意义，它应该在无法获得 dpkg 数据库的读取锁定时立即退出。
看来我不是唯一一个遇到麻烦的人。所有建议都apt-check非常负面：
（清理浏览器，未登录，无个性化搜索）
答案1
一些深入研究apt-check给了我这些线索，表明这是一个需要修复的非常粗暴的脚本。尽管我非常尊重它的作者，但它在我的服务器上失败了。以下是我的想法：
apt-check==/usr/lib/update-notifier/apt_check.py- 强制将 nicelevel 设置为 19
- 未对操作设置超时
最后两者的结合使得进程数量不断增加，呈螺旋式下降。如果系统用于其他优先级更高的用途，进程数量只会增加，而且没有尽头，因为apt-check进程永远不会获得任何优先级。一旦 OOM 杀手决定杀死您的重要系统进程，问题只会变得更糟。
我认为，如果这两个行为方面中的任何一个有所不同，系统就不会陷入如此崩溃的状态。
尽管字符串是正确的关于父进程也应承担的责任，我认为以下几点存在缺陷apt-check，必须将其报告为错误才能得到妥善解决：
- 它应该提示OOM杀手先被杀死
- 它不应该设置 nicelevel 硬编码
- 如果获取信息的时间过长，它应该退出
实际上，Linux OOM 杀手似乎正在对此进行一些启发式处理。经过优化的进程将获得更高的分数，而长时间运行的进程将减少分数。（来源- 谢谢乌尔里希·丹格尔为了指出它）
我可能提出的解决方案是：
- 处理后缓存结果
- 如果少于 N 秒，则输出缓存无需为每次简单（甚至
--help）调用加载所有 Python-APT 库。 - 使 nicelevel 可配置 -请允许我更改/禁用此功能！我相信将其设置为 0 实际上会有所帮助
- 让它增加 OOM 杀手分数
答案2
您需要找出哪个进程正在生成 apt-check。您可以使用 ps 之类的命令来获取进程树。
ps -A --forest
如果 apt-check 没有父级，那么可能是 apt-check 自身的问题，而不是某个特定程序的问题。如果是这种情况，我会尝试调试 apt-check。
答案3
基于 Ubuntu 12.04 编写
我遇到了同样的问题，发现这是因为byobu，如果我只运行apt-get update而不使用byobu，就不会有任何check-apt进程。此外，它与包有关update-notifier，当我删除那些包（update-notifer-common、update-notifier）时，使用byobu并运行apt-get update，它运行了另一个命令，但使用内存完全相同：apt-get -s -o Debug::NoLocking=true upgrade。
其他一些东西可能会运行apt-get update（但可能不会运行check-apt）
- 将参数传递给
check_apt更新/升级包。 - 如果已配置，
/etc/cron.daily/apt也可能更新软件包列表（请参阅https://help.ubuntu.com/lts/serverguide/automatic-updates.html)，但它每天只运行一次，应该不会有问题。
在桌面上，可能涉及更多的东西。
总结： 在运行并触发这些进程byobu时捕获事件，重新配置状态栏以解决这个问题。apt-get updatecheck-aptbyobu