PID сбежал со всеми нашими MEM и жестко ЗАМЕНИЛСЯ - OSSEC RHEL

Простите меня за длину этого вопроса ... это в основном детали ... только попытка следовать, если вам также нравится читать файлы журнала ... или пить кофе.

Сначала я сформулирую вопросы:

1) как, черт возьми, сработал нано-процесс, основываясь на том, что я сказал ниже

2) как nano удалось забрать столько ресурсов

3) работа с перезапусками ossec, конечно, не случайность, это связано?

Это среда Red Hat 4.1.2-46 XEN, три члена кластера. Мы вручную обновили код мониторинга ураганов 17 января в 11:34. Два файла были изменены (с помощью nano) при ossec бегал:

preloaded-vars.conf
ossec.conf

Затем ossec был перезапущен, а затем пользователь root вышел из системы.

К сожалению, три сервера перешли в автономный режим (все еще был ssh), потому что процесс nano сбежал (я предполагаю, что это могло бы произойти, если бы я использовал VI, поэтому тип редактора не подлежит сомнению). Как ни странно, ни один крон не запустил службу 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 занял ~ 28 ГБ оперативной памяти.

На отключение наших серверов ушло чуть больше трех дней. Я нашел кое-что еще, прежде чем убил процесс. Обратите внимание, что процесс nano начался через два часа после того, как файл был впервые отредактирован и 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 (см. R перед статистикой использования ЦП)

Дополнительные замечания. Файл preloaded-vars.conf был создан из файла .tar (следовательно, 1000: 1000). Отредактировал рут. Файл .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 по умолчанию заключается в создании файла preloaded-vars.conf.save при получении сообщения SIGHUP или SIGTERM. До сих пор не понимаю, что заставило его сойти с рельсов.