原谅我这个问题的长度…这是主要的细节…只尝试跟随，如果你也喜欢阅读日志文件… …或喝咖啡。
我将首先陈述问题：
1）基于我在下面陈述的内容，纳米过程是如何发生的
2）纳米如何pipe理这么多的资源
3）与ossec重新启动肯定不是巧合，所以是相关的？
这是Red Hat 4.1.2-46 XEN环境中的三个集群成员。 上午11:34，我们在1月17日手动更新了我们的飓风监测代码。 在ossec 运行时，更改了两个文件（使用nano）：
preloaded-vars.conf ossec.conf ossec然后重新启动，然后root用户注销。
不幸的是，三台服务器都离线了（仍然有ssh），因为一个纳米进程跑了（我想如果我使用了VI，那么编辑器types不会有问题）。 奇怪的是，没有crons启动纳米服务，当时没有人login到服务器，我确信我已经正确closures了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
注意：纳米编辑占用了大约28GB的内存。
花了三天时间才把服务器关了。 在我杀死这个过程之前，我发现了其他的东西 请注意，纳米进程在文件第一次编辑之后两个小时才开始，root登出。 注意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）创build的。 它是由根编辑的。 .sav文件是在我杀死nano的时候创build的（它比主文件小）。 在两台Xen服务器上，纳米卡住了编辑preloaded-vars.conf，第三个纳米卡住了编辑ossec.conf文件。 纳米死亡时不会创buildossec.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文件，然后从另一个terminal杀死pid，nano的默认行为是在接收SIGHUP时创build一个preloaded-vars.conf.save文件或SIGTERM消息。 还是不明白是什么原因导致它走上轨道。
那么，（2）的答案可能是“你没有任何资源限制configuration” – 检查ulimit来解决这个问题。
对别人没有任何线索。