☰

PID 占用了我们所有的 MEM 并硬交换 - OSSEC RHEL

tag-icon • tag-icon redhat xen ossec
PID 占用了我们所有的 MEM 并硬交换 - OSSEC RHEL

请原谅我问的这么长...它主要是细节...只有当你也喜欢阅读日志文件...或喝咖啡时才尝试关注。

我先陈述一下问题：

1）根据我下面所述，纳米工艺到底是如何实现的

2）Nano 是如何获取如此多资源的

3）与 ossec 重启一起工作肯定不是巧合，那么这有关系吗？

这是一个 Red Hat 4.1.2-46 XEN 环境，有三个集群成员。我们于 1 月 17 日上午 11:34 手动更新了 Hurricane 监控代码。在 ossec 期间，两个文件被更改（使用 nano）正在运行：

preloaded-vars.conf
ossec.conf

然后重新启动 ossec 并注销 root 用户。

不幸的是，由于 nano 进程失控，三台服务器都离线了（仍然有 ssh）（我想如果我使用 VI 就会发生这种情况 - 因此编辑器类型没有问题）。奇怪的是，没有 cron 启动 nano 服务，当时也没有人登录服务器，我确信我已正确关闭 nano。在我关闭 PID 之前，top 为我提供了以下见解：

Mem:  28359680k total, 28325064k used,    34616k free,     3424k buffers
Swap:  4194296k total,  4194296k used,        0k free,    70208k cached
PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
26351 root      18   0 29.7g  25g  784 R 100.1 95.6   4424:38 nano

注意：nano 编辑器占用约 28GB 的​​ RAM。

这件事花了三天多的时间才导致我们的服务器瘫痪。在终止该进程之前，我发现了其他东西。请注意，在文件首次编辑并注销 root 权限后两小时，nano 进程才开始。请注意 tty = ?。

# ps -ef | grep nano
root      7836  7689  0 13:19 pts/5    00:00:00 grep nano
root     26351     1 99 Jan17 ?        3-01:44:46 nano /opt/ossec/etc/ossec.conf

值得庆幸的是，在我关闭 PID 之后，我得到了：

Mem:  28359680k total,  1189924k used, 27169756k free,     4584k buffers
Swap:  4194296k total,   260284k used,  3934012k free,   104352k cached

我首先期望发现进程状态是stopped或traced但事实却是running（参见 %CPU 使用率统计之前的 R）

附加说明。preloaded-vars.conf 文件是从 .tar 文件创建的（因此是 1000:1000）。它由 root 编辑。.sav 文件是在我关闭 nano 时创建的（它比主文件小）。在两台 Xen 服务器上，nano 一直无法编辑 preloaded-vars.conf，而在第三台服务器上，nano 一直无法编辑 ossec.conf 文件。nano 被关闭时没有创建 ossec.conf.save。

-rwxr-xr-x  1 1000 1000  2918 Jan 17 11:04 preloaded-vars.conf
-rw-------  1 root root  2909 Jan 20 13:13 preloaded-vars.conf.save

进一步的发现： 我发现，如果我打开 preloaded-vars.conf 文件，然后从另一个终端杀死 pid，nano 的默认行为是在收到 SIGHUP 或 SIGTERM 消息时创建 preloaded-vars.conf.save 文件。仍然不明白是什么导致它一开始就出轨了。

答案1

嗯，(2) 的答案可能是“您没有配置任何资源限制” - 检查 ulimit 来解决这个问题。

但其他情况就没有任何线索了。

相关内容